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Li  desirable  for  both  current  and  future  applications  and  to  produce  a 
document  that  vould  assist  the  users  in  the  utilizations  of  these  tools. 

Acknow1 edgement  is  given  to  the  TSC  project  technical  monitor. 

Hr.  Robert  Wiseman,  for  his  effective  guidance,  participation,  and 
contribution  to  many  technical  areas,  particularly  in  the  development 
of  new  approaches  to  maximize  the  efficiency  of  field  data  collection 
and  reduction,  data  base  update,  and  model  verification.  We  also  wish 
to  acknowledge  the  contributions  of  Dr.  Mitchell  Grossberg  of  TSC  who 
investigated  and  documented  the  feasibility  of  new  proced  igjss  for  auto- 
matic source  data  reduction;  and  Mr.  William  Petruzel  oi  FAA  who  gave  us 
much  needed  guidance  and  advice  in  th^  preparation  of  this  report. 

This  project  was  directed  by  Dr.  Paul  Tuan,  the  Project  Leader,  under 
the  supervision  of  Dr.  Robert  Ratner,  SRl's  Transportation  Center  Director. 
Hr.  Steven  Procter  was  responsible  for  the  refinements,  modifications,  and 
documentation  of  the  Air  Traffic  Flow  (ATF)  model;  and  Dr.  George  Couluris 


SI  Safer 

Si  igl 


I*  Si  I 
5‘  §•  I 

-l*j  §• 

IIS  * 

S i 


nr, 


was  responsible  for  Che  description  of  the  Relativ-  Capacity  Estimating 
Process  (RECEP)j  the  integration  of  past  and  current  RESEP//‘TF  applica- 
tion features,  and  the  development  of  an  example  case  study  illustrating 
the  methods  of  utilising  the  tools  developed. 


CONTENTS  (CONT.) 


Sectlor 


3.3.  Index  of  Orderliness. 


3.3.L.  A Brief  Definition 

3.3.2.  Filtering  and  Weighting  Fromulas, 

3.3.3.  A Possible  Comparison 


DESCRIPTION  OF  THE  RELATIVE  CAPACITY  ESTIMATIN'  PROCESS.. 


4.1.  Background. 


4.2.  Description. 


4.2.1.  Routine  Work.. 

4.2.2.  Surveillance  Work 

4.2.3.  Conflict  Processing  Work 

4.2.4.  Workload  and  Capacity  Calibration. 


4.3.  Data  Collection  and  Reduction. 


4.3.1.  Team  Routine  Work  Measurement 

4.3.2.  R-Controller  Routine  Work  Allocation 

4.3.3.  R-Controller  Surveillance  Work  Calculation. 

4.3.4.  Potential  Conflict  Work  Measurement 

4.3.5.  Sector  Traffic  Capacity  Estimation......... 

4.3-6.  Alternative  Sector  Manning  Strategy 

Analysis 


4.4.  RECEP/ATF  Interface. 


4.5.  RECF.P  Data  Base  Update  and  Model  Verification. 


4.5.1.  RECEP  Data  Base  Update. 

4.5.2.  Model  Verification 


DESCRIPTION  OF  THE  AIR  TRAFFIC  FLOW  MODEL. 


5.1.  Model  Overview. 


5*2.  Assumptions  and  Limitations. 


5.3.  M'  del  Components. 


5*4.  Input  and  Output  Spec i f I nil  inns. 


5.4.1.  Inpul . 

5.4.2.  Output 


•r> 

105 


CONTENTS  (MINT.) 


Section 


5.5-  Modt  Applications. 


5.5.1.  Evalua ;ion  of  Automation  Packages... 

5.5.2.  Evaluation  of  Operations  and  Procedures... 
5-5.3.  Evaluation  of  ATC  Manpower  Allocations.... 

5.6.  Data  Base  Update  and  Model  Verification 

EXAMPLE  OF  RF.CEP/ATF  APPLICATION  IN  PRODUCTIVITY 

analyst; 


6.1.  KKCKP  Dunums  i ra  t Ion. 


6.1  1.  Handoff  Augmentation.. 

6.1.2.  Sector  Conflict  Probe. 

6.1.3.  Renarkp 


6.7..  ATF  Application. 


6.2.1.  Control  Operations  Modeling. 

6.2.2.  Productivity  Comparisons. .. . 


APPENDIXES 


RECORD  FORMAT  FOR  FNROUTE  WORK  ACTIVITY  MEASURES. 


B SECTOR  BUSY  HOUR  IDENTIFICATION  WITH  A WORKPACE 
SEARCH  PROGRAM 


EQUIVALENCE  RELATIONSHIPS  BETWEEN  RECEP  AND  WORK  ACTIVITY  .. 


D POTENTIAL  CONFLICT  MODELS. 


DATA  V.OLI  EC's;  ION  AND  REDUCTION  TECHNIQUES  FOP.  POTENTIAL 
CONFLICT-EVENT  FREQUENCY 


USE  OF  DART  FOR  QUICK  ESTIMATION  OF  R?CEP  FDP/Rl'P  AND 
AIRCRAFT  LOAD  COUNTS 


A SUGGESTED  FIELD  TEST  PROCEDURE  FOR  RECEP  AND  THE 
AT?  MODEL 


H THE  SECTOR  SPLIT  MODEL. 


I REPORT  OF  INVENTIONS. 


REFERENCES. 


.iy#ihuiMiU!t,i  tu. ijiiniHiifft! jit  uuHiuMiiAi(iuu.Hblbit[ittk.i>iuinau>!i(iEidRuiitiLRik|lteiife  LnlfuAWilii  ItaWlftiUlk  a dJ  JlaJfliMi.V5M  t.  kMWM  II  ik iMfe; jfegj olwl  # 


ILLUSTRATIONS 


A GPSS  Model  for  Voice  Channel  Utilization 


Sector  Team  Workload  Calibration 


Atlanta  Center  Multisector  Study  Area 
Schematic  of  Study  Area  Route  Model 


10- Sector  Delay  ...........  ..  125 

11- Sector  Delay  125 

Productivity  Relationships  ..  129 

RECEP  Data  Collection  and  Reduction  on  Potential  Conflict 
Events — Major  Steps 154 

An  Example  of  a Sector's  Operational  Routes 

and  Intersections 158 

Probable  Workpace  and  RECEP  Curves  for  a Hypothetical 

Sector  173 


TABLES 


1 Enroute/Terminal  Work  Activity  Codes. 


Workpace  Definitions. 


Radar -Controller  Workload  Calibration 


Observed  Number  of  Air/Ground  Communications, 
Current  NAS  Stage  A,  Atlanta  Center  . . . . . 


Observed  Number  of  Interphone  Coamtunlcarions  and  New 
Flight  Strip  Preparations,  Current  NAS  Stage  A, 
Atlanta  Center 


Observed  Number  of  FDP/RDP  Operations,  Current 
NAS  Stage  A,  Atlanta  Center  

Number  of  Routine  Control  Events,  Current  NAS 
Stage  A,  Atlanta  Center  


8 Routine  Event  Frequency  Estimates,  Atlanta  Center, 
Tuo-Man  Sector  Operations,  System  1A — NAS  Stage  A Base 

9 Routine  Event  Minimum  Performance  Time  Estimates 
Two-Man  Sector  Operation,  System  1A — NAS  Stage  A Base. 

10  Routine  Control  Event  Sector  Team  Activities,'- 

Current  NAS  Stage  A 


R- Controller  Routine  Event  Minimum  Performance  Time 
Estimates, Atlanta  Center,  Two-Man  Sector  Operation,  System 
IA — NAS  Stage  A Base  ...  


12  R-Controllcr  Surveillance  Workload  Weighting,  by  Sector 
Atlanta  Center,  Two-Kan  Sector  Operation  System  1A— NAS 
Stage  A Base 

1'i  Conflict  Event  Performance  Time  Estimates,  Atlanta  Center, 
Two-Man  Sector  Operation, System  LA — NAS  Stage  A Base  . . 

14  Estimated  Frequency  of  Conflict  Events  per  Sector  Atlanta 
Center,  Two-Man  Sector  Operation,  System  1A — NAS  Stag*.  A 


15  Workload  Weightings,  Atlanta  Center,  Two-Man  Sector 

Operation  System  1A--NAS  Stage  A 


hlimwi*>|i|l  **»«■*« MM Mtt udf MM t M0lft4MMIlMUmnMMMIIMIMfcMKi<MIMMNMMNIMMMMMMMnA MMMKM 't'1.-  


16  Sector  Traffic  Capacity  Estimated,  Atlanta  Center, 

Two-Man  Team  Operation,  System  iA — NAS  Stage  A Base 76 

17  R-T  Team  Routine  Event  Minimum  Performance  Time 
Estimates,  Atlanta  Center,  Three-Man  Sector 

Operation,  System  IB — NAS  Stage  A Base » ?9 

18  AFT  Output 106 

19  R-D  Team  Routine  Event  Mini;  aim  Performance  Time  Estimates 
Two-Man  Sector  Operation,  System  2 — Automated  Data 

Handling 119 

20  Conflict  Event  Performance  Time  Estimated,  Atlanta  Center, 

Two-Man  Sector  Operation,  System  4 — Sector  Conflict  Probe  . 121 

21  Events  Resulting  in  Violation  of  Radar  Separation  Minima  . . 146 

22  List  of  Source  Data  Elements  for  Potential 

Conflict  Events.  157 

23  Typical  Traffic  Distribution  Example  159 

24  Potential  Intersection  Conflicts  160 

25  Overtake  Conflicts  (0AL-M0D  Route)  161 

26  Routine  FDP/RDP  Control  Events  166 

27  Sample  of  Dart  Track  Printout  to  Identify 

Controlling  Sector 169 


x 


ACRONYM  LIST 


* 

L' 


i 


A/G  Atr/Ground 

ARTCC  Air  Route  Traffic  Control  Center 

ARTS  Automated  Radar  Terminal  System 

ATC  Air  Traffic  Control 

ATF  Air  Traffic  Flow 

CRD  Computer  Readout  Davice 

DART  Data  Analysis  ar.d  Reduction  Tool 

DSF  Digital  Simulation  Facility 

FAA  Federal  Aviation  Facility 

FDP  Flight  Data  Processing 

GPSS  General  Purpose  System  Simulation 

NAFEC  National  Air  Facility  Experimental  Center 

NAS  National  Aviation  System 

PVD  Plan  Viev  Display 

RDP  Radar  Data  Processing 

RECFT  Relative  Capacity  Estimating  Process 

SAR  System  analysis  and  Recording 

SRI  Stanford  Research  Institute 

TATF  Terminal  Automatic  Test  Facility 

TRACON  Terminal  Radar  Approach  Control 

TSC  Transportation  Systems  Center 

UG3RD  Upgraded  Third  Generation 

VCU  Voice  Channel  Utilization 

WA  Work  Activity 

WP  Workpace 


xi 


KiMift  "alii  ■ Mm  n«  ■n-fam'-a  *■&■)(*  d».i»  iin\8,Mii  * fa*Vi A'iWlii'ilai  »iwP'Pii  .WW  M 


i 


EXECUTIVE  SIMiARY 


Introduction 

This  report  is  a description  of  the  evaluation  methodologies  that 
have  been  used  by  SRI  in  air  traffic  control  (ATC)  productivity  analyses 
performed  for  the  FAA.  The  models  and  techniques  involved  in  these 
analyses  have  been  successively  modified  and  refined  over  the  past  years. 
More  recently,  under  a contract  awarded  by  the  Transportation  Systems 
Center,  SRI  was  given  the  opportunity  to  examine  the  models  and  their 
applications  in  order  to  consolidate  and  Improve  those  features  that 
are  considered  to  be  desirable  for  both  current  and  future  applications. 
The  purpose  of  this  report  is  to  document  the  major  application  areas 
and  the  analysis  method  used  with  an  integrated  approach  in  order  to 
assist  the  FAA  in  the  use  of  these  tools. 

The  techniques  of  modeling  have  long  been  an  important  tool  to 
engineers,  scientists,  and  operational  analysts.  The  basic  motivation 
for  using  models  in  air  traffic  control  productivity  analysis  is  the 
search  for  more  knowledge  about  current  systems  and  to  predict  the  be- 
havior  of  future  systems.  Examples  of  such  applications  are:  (1)  the 

modeling  of  increased  (or  decreased)  traffic  demand  of  an  existing 
system;  (2)  the  testing  of  a modified  sector  organization;  (3)  the 
evaluation  of  a new  congestion-relief  strategy  that  has  yet  to  be 
proven  prior  to  actual  field  implementation;  and  (A)  the  evaluation 
of  the  impact  of  proposed  future  automation  packages.  The  models 
described  here  include  the  Relative  Capacity  Estimating  Process  (RECEP), 
which  relates  controller  workload  to  sector  traffic  capacities,  and 
the  Air  Traffic  Flow  (ATF)  network  simulation  model,  which  assesses 
traffic  capacity  and  delay  in  a multisector  environment. 


Relative  Capacity  Estimating  Process  (RECEP) 

'1  ,e  RECEP  modeling  approach  estimates  the  traffic-handling  capa- 
bilities of  an  individual  sector  by  encoding,  as  a set  of  discrete  events, 
the  controller  work  associated  with  the  sector's  operational  require- 
ments. RECEP  models  are  mathematical  representation  of  the  routine, 
surveillance,  and  conflict-processing  workload  components  of  a sector 
team.  Routine  work  tasks  involve  air/ground  (A/G)  voice  communications; 
flight  data  processing  (FDP)  and  radar  data  processing  (RDP)  manual 
data  entry/display  operations;  flight-strip  data  processing,  intersector 
interphone  voice  communications;  and  intrasector  direct  (face-to-face) 
voice  communications.  Surveillance  work  is  visual  observation  of  radar- 
derived  aircraft  situation  data  on  a plan  view  display  (PVD).  The  sur- 
veillance workload  time  increases  in  direct  proportion  to  sector  flight 
time;  therefore,  surveillance  work  is  sensitive  to  the  geographic  size 
of  a sector  as  well  as  the  traffic  flow  rate.  Conflict  processing 
work  (for  potential  crossing  and  overtake  conflicts)  includes  potential- 
conflict  recognition,  assessment,  and  resolution  decision  making  and 
A/G  voice  communications.  The  conflict-workload  weightings  calculated 
for  one  sector  would  differ  from  those  of  another,  depending  on  the 
complexity  of  each  sector's  route  structure.  The  workload  weighting 
is  derived  by  using  a potential  of  four  separate  equator's  modeling 
a variety  of  aircraft  crossing  and  merging  situations  (level-level, 
level-transitional,  transitional-transitional,  and  overtake). 

A sector  RECEP  model  is  an  additive  reconstruction  of  the  above 
three  workload  components  measured  in  time-based  units  (e.g.,  man- 
minutes  of  work)  which  include  minimum  task  performance  and  are  associated 
with  the  sectors'  control  operations.  The  advantages  of  using  minimum 
performance  times  are:  (1)  to  avoid  the  necessity  of  a detailed  and 

extremely  difficult  accounting  of  overlapping  task  situations,  and 
(2)  that  the  minimum  performance  time  is  more  likely  to  be  invariant 
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over  time  and  location;  therefore,  it  is  a much  more  reliable  measure 
than  average  or  actual  times. 

RECEP  is  used  to  estimate  the  traffic  capacities  of  individual 
sectors  under  alternative  operating  modes.  The  capacity  estimates 
correspond  to  baseline  and  proposed  system  operations,  as  well  as  fea- 
sible sector  manning  strategies  (i.e.,  one-man,  or  two-man  sector  teams). 
RECEP  is  also  used  as  the  basis  for  first-order  estimation  of  the 
capacity  effects  of  sector  splitting. 

As  a result  of  various  ATC-related  data  collection  exercises,  SRI 
has  developed  a data  collection/reduction  procedure  for  NAS  Stage  A 
equipped  enroute  facilities  that  is  based  on  the  following  data  sources: 

• Video  tape  recordings  of  PVDs. 

• Audio  (including  video  tape  sound  track)  recordings  of  A/G 
and  interphone  corrmunications. 

• Manual  recordings  of  observed  controller  physical  actions. 

• NAS  Stage  A data  analysis  and  reduction  tool  (DART)  computer 
printout  records  of  R and  D position  FDP/RDP  operations. 

• Flight  strips,  used  and  marked-on  by  the  controller. 

It  is  important  to  note  that  a significant  portion  of  the  work 
performed  by  the  controller  involves  routine  tasks.  For  this  reason, 
a special  data  reduction  process  is  developed.  This  process  requires 
that  data  measurements  be  assembled  into  a format  that  facilitates  cross- 
reference  of  theobserved  activities  and  permits  a reconstruction,  in 
part,  of  the  routine  control  events.  The  information  on  operational 
procedures  obtained  during  the  controller  interviews,  along  with  the 
data  observations,  is  essential  to  Identify  the  control  requirements 
that  are  in  the  logical  reconstruction  of  routine  events.  The  RECEP 
data  base  update  and  model  verification  are  required  periodically  to 
maintain  its  validity  as  a reliable  measuring  and  predicting  tool.  A 
number  of  procedures  are  suggested  in  this  report  to  accomplish  this 
task. 
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Air  Traffic  Flow  Model  (ATF 


ATF  is  a computerised  network  simulation  of  multisector  air 
traffic  route  flows  in  which  the  air  route  network  is  partitioned 
into  control  sectors.  That  is,  the  route  network  is  represented  by  a 
connected  series  of  route  segments  (arcs),  where  each  segment  represents 
a directed  flow  of  aircraft  through  one  sector.  Every  sector  contains 
a set  of  route  segments,  each  of  which  is  connected  at  either  end 
to  route  segments  of  adjacent  sectors;  the  first  end  las-  route  seg- 
ments connect  to  sector  boundaries  that  include  terminals.  For  the 
purpose  of  proper  accounting,  when  two  or  more  separate  route  segments 
are  merged  into  or  demerged  from  a single  route  within  a sector,  these 
route  segments  are  defined  as  separate  routes.  The  connected  route 
segments  enable  ATF  to  trace,  over  time,  aggregate  traffic  flows  from 
sector  to  sector,  and  thereby  represent  multisector  traffic  activity 
without  actually  tracking  individual  aircraft  trajectories  (an  attribute 
that  reduces  calculation  requirements  and  computer  run  costs). 

Because  the  route  segments  are  partitioned  into  sectors,  the 
number  of  aircraft  on  each  route  segment  during  some  small  time  incre- 
ment (e.g.,  one-minute)  provides  a convenient  means  to  calculate 
readily  the  number  of  aircraft  through  each  sector.  These  data,  together 
with  RECEP-based  sector  workload  capacity  relationships,  are  used  in 
ATF  to  determine  the  degree  of  traffic  saturation  of  each  sector  team. 

The  ATF  model  operation  loads  traffic  onto  the  multisector  network, 
moves  traffic  from  sector  to  sector  at  successive  time  increments, 
and  searches  for  sector  team  traffic  saturation  conditions.  When 
imminent  saturation  situations  are  found,  an  ATF  congestion-relief 
algoric:..i  selectively  delays  aircraft  in  order  to  resolve  the  traffic 
congestion  conditions.  In  essence,  the  congestion-relief  algorithm  dis- 
tributes workload  to  upstream  sectors  to  prevent  a downstream  sector 
team  work  overload.  ATF  traces  the  propoagation  of  traffic  congestion 


and  delays  through  the  network  over  time  and  calculated  oircrcft 
average  deluy  atuLiu-'icH.  In  addition,  the  number  of  aircruft  and 
the  individual  sector  workload  values  are  also  recorded. 

ATF  has  kM-en  used  to  estimate  the  average  aircraft  delay  experienced 
during  some  time  interval  of  interest  (e.g.,  2-hour,  3-hour,  or  8-hour 
intervals  as  may  be  chosen  by  the  analysts)  ir>  a selected  multisector 
environment  for  a range  of  traffic-loading  projections.  The  multisector 
environment  is  defined  by  specifying  the  route  network  structure  and 
control  operation,  baseline  or  proposed.  The  control  operation  is 
represented  by  the  RECEP-based  workload-capacity  relationships  determined 
for  each  feasible  combination  of  baseline  or  proposed  system,  sector 
manning  strategy,  and  seeforization  configuration.  For  the  purpose  of 
productivity  analysis,  we  determine  and  compare  the  average  aircraft 
delays  corresponding  to  the  various  control  operations  while  holding 
the  route  structure  fixed. 

The  types  of  input  data  may  be  classified  into  the  following 
groups: 

• Network  composition  (sectors,  routes,  and  arcs) 

• traffic  flow  parameters 

• Sector  workload  maxiau* 

• Sector  workload  coefficients 

• Congestion-relief  strategy. 

Output  from  the  model  is  printed  as  often  as  each  time  increment 
or  at  any  other  frequency  desired.  The  amount  of  information  displayed 
at  each  print  cycle  can  also  be  controlled. 

The  three  parameters  that  could  be  used  for  analysis  of  an  ATC 
airspace  are  average  delay  per  aircraft,  traffic  capacity,  and  controller 
workload.  These  three  elements  are  dependent  upon  each  other.  Given 
two  of  the  elements,  the  third  can  be  calculated. 
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Model  Applications 

RECEP  and  ATF  are  designed  to  allow  modification  and  flexibility 


to  their  design  structure,  and  thereby  enable  their  application  to 
various  areas  of  study.  The  RECEP  event  task  times  and  frequencies 
may  be  used  to  represent  various  operational  requirements  and  strategies; 
ATF  parameters  may  be  used  to  represent  alternative  sectorixntion  and 
routing  structures.  The  possible  areas  of  application  for  RECEP/ATF 
include,  but  are  not  restricted  necessarily  to: 

• Evaluation  of  automation  packages 

• Evaluation  of  operations  and  procedures 

• Evaluation  of  ATC  manpower  allocation 

• Testing  of  productivity  measures 

• Energy-consumption  evaluation. 

To  date,  RECEP/ATF  has  been  applied  explicitly  to  the  first  area 
of  study  listed — evaluation  of  automation  packages.  However,  this 
application  has  used  techniques  that  could  be  extended  to  the  other 
areas  of  study.  The  last  section  (Section  VI)  of  this  report  gives 
an  example  of  RECEP/ATF  application  in  Productivity  Analysis.  A 
hypothetical  automation  package  that  includes  Handoff  Augmentation  and 
Sector  Conflict  Probe  automation  items  is  used  to  exemplify  the  RECEP 
analyses  technique  and  to  illustrate  the  means  by  which  ATF  is  used  to 
develop  productivity  measures. 

Other  Related  Measures  and  Models 


Three  other  related  measures  and  models  are  surveyed  to  develop 
a comparison  with  the  RECEP/ATF  methods.  They  are:  (l)  Workpace  and 

Work  Activity  Measures,  WP/WA;  (2)  Voice  Channel  Utilization,  VCU;  and 
(3)  Index  of  Orderliness,  1.0. 
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The  major  dii'J'erencca  between  RECEP  end  WP/WA  (the  WP/WA  is  not 
a multisector  network  model;  therefore  a comparison  cannot  be  made 
with  ATF)  & re:  (1)  the  treatment  of  potential-conflict  workload; 

(2)  standard  time  vs.  actual  time;  and  (3)  data  resolution.  The  cor- 
respondence elements  of  WP/WA  and  RECEP  can  only  be  dons  on  an  aggregative 
basis. 

The  VCU  simulation  could  be  compared  with  ATF  only  on  a sector -by- 
sector basis.  The  most  reasonable  output  available  for  direct  com- 
parison would  be  aircraft  load  using  time-series  representations.  Another 
method  that  may  be  investigated  i3  to  assume  that  VCU  constituted  all 
of  the  workload  at  *ach  sector.  This  method  would  require  a comparison 
of  VCU  average  ti ne  and  frequency  products  against  total  RECEP  workload 
estimates.  However,  because  VCU  is  an  Indirect  measure  of  workload 
and  may  not  reflect  all  controller  activity,  such  a comparison  may  at 
best  only  indicate  proportionality  between  ;he  results. 

The  index  of  orderliness  might  be  a useful  tool  to  provide  an 
estimate  of  potential-conflict  events  as  mcx-deled  '_n  RECEP.  This  would 
have  two  belief its.  The  first  is  that  it  would  provide  substantiating 
evidence  regarding  the  validity  of  RECEP  conflict  count,  and  the  second 
is  that  it  might  provide  a less  complex  method  for  estimating  potential 
conflict  frequencies.  One  can  hypothesize  that  there  may  be  a correla- 
tion between  the  Index  and  the  number  of  occurrences  of  aircraft  pairs 
within  s cylindrical  voluaie  of  radius  and  height,  centered  0\t  one  of 
the  aircraft.  If  this  is  assumed  to  be  true,  then  the  Conflict  Alert 
option  in  the  DART  printout  provides  a met  an  s for  »,  rough  equivalence 
between  the  two  techniques. 
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1.  INTRODUCTION 


1.1  SIMULATION  MODEL  IN  GENERAL 

1.1.1  Definition  of  Simulation  Models 

The  technique  of  simulation  has  long  been  an  important  tool 
to  engineers,  scientists,  and  operational  analysts.  In  a broad  sense, 
simulation  includes  physical  replication  of  real  operational  objects 
in  scale  models,  for  example,  to  simulate  airplane  flight  with  scale 
mo<'ils  of  airplanes  in  a wind  tunnel,  to  simulate  space  vehicle  control 
with  a ground-based  train* r.  With  the  advent  of  electronic  digital 
computers,  simulation  has  taken  on  a new  dimension  which  encompasses 
a broad  spectrum  of  applications  including  econometric  models,  military 
war  games,  corporate-planning  models,  freeway  simulation,  hospital  simu- 
lation, etc.  The  types  c\f  users  range  from  engineers  and  scientists 
to  business  planners,  operational  managers,  psychologists,  and  admin* 
istrators.  In  the  context  of  this  report,  simulation  models  connote 
digital  computer  simulation.  A definition  can  be  stated  as  follows: 

A computer-simulation  model  is  a procedural-iogical- 
raathematical  representation  of  s real-world  system 
programmed  for  digital  computers  within  which  experi- 
ments can  be  conducted  over  specific  periods  of  time. 


1.1.2  Utility  of  Simulation  Models 

The  basic  motivation  for  using  sluulation  in  air  traffic 
control  (ATC)  productivity  analysis  is  the  search  for  more  knowledge 
about  current  systems  and  to  predict  the  behavior  of  future  systeus. 
It  may  be  either  impossible,  unsafe,  or  impractical,  or  too  costly  to 
observe  a proposed  process  in  a real-world  environment.  For  example, 
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it  would  be  Impossible  to  perform  field  experiments  on  a future  automa- 
tion system  when  the  system  is  not  even  installed  and  no  substitution 
can  be  made.  It  would  also  be  impractical  and  very  costly  to  test  a 
set  of  resec tor izat ion  pla>is  at  a center  which  would  involve  procedural 
and  manpower  changes. 

Simulation  may  be  used  when  the  complexity  of  the  system  in 
question  is  beyond  analytical  or  mathematical  approaches.  A typical 
example  is  a traffic  network  where  there  are  sequential  queues  and 
multiple  servers.  The  air  traffic  operation  of  an  Air  Traffic  Control 
termiual  or  center  generally  is  in  this  category. 

The  utility  of  a simulation  model  in  air  traffic  control  can 
be  generally  summarized  as  follows: 


• To  use  simulation  as  a preliminary  test  to  try  out  new 
procedures,  operating  priorities,  etc.,  before  actual 
field  experimentation. 

• To  use  simulation  as  an  evaluation  tool  for  comparing 
the  merits  of  several  competing  system  proposals  under 
constrained  resources. 

• Simulation  can  be  regarded  as  a "drafting  board"  for 
systems  design.  The  rapid  response  from  a computer 
simulation  can  lead  to  design  improvements  within  a 
short  period. 

• Simulation  studies  often  enable  the  practitioner  to 
understand  and  gain  insight  of  the  current  system,  for 
example,  the  interrelationship  among  system  parameters 
or  the  sensitivity  of  variable  vulues. 

• Simulation  can  be  used  as  a training  tool  for  opera- 
tional managers,  planners,  and  policy  makers  to  utilize 
quantitative  and  dynamic  analysis  as  a tool  for  decision 
making. 


1,1.3  Types  of  Simulation  Models 

Although  there  are  many  ways  to  classify  simulati-i  models, 
for  the  purpose  of  this  report  we  choose  to  group  models  by  . _ technique 


with  which  the  simulation  "clock  time"  is  being  advanced.  Clock  time 


is  a computer  software-maintained  timing  mechanism  which  "drives"  the 
simulation  from  one  time  point  to  the  next.  The  clock  time  simulates 
the  real-world  time  units  (e.g.,  seconds,  minutes,  hours,  days)  as  may 
be  defined  by  the  user.  Each  time  the  simulation  is  advanced  by  an 
increment  of  time  the  computer  would  update  the  "state"  of  the  system 
by  performing  the  necessary  logical,  computational,  and  housekeeping 
functions  railed  for  by  the  model  software.  There  are  two-  general 
types  of  methods  for  simulation-time  progression:  (1)  fixed-time 

increment,  and  (2)  variable-time  increment. 

The  fixed-time  increment  method  is  also  referred  to  as  "uniform 
time-step"  or  "synchronot.."  method.  As  the  names  imply,  the  state  of 
the  simulation  system  is  examined  and  updated  at  every  At  which  is  a 
fixed-time  interval  predefined  by  the  simulation  user.  The  variable- 
time increment  method  is  also  known  as  "event  step,"  or  "asynchronous" 
method  which  suggests  that  the  advancement  of  simulation  clock  time  is 
determined  by  the  amount  of  time  necessary  to  cause  th^  next  most  imminent 
event  to  occur.  After  the  event  and  its  related  system  components  have 
been  updated,  the  clock  time  is  again  advanced  by  another  variable  time 
increment  (if  the  simulation  continues).  The  determination  of  which 
method  to  use  in  the  design  of  a simulation  model  would  depend  on  the 
nature  of  the  system.  Generally  speaking,  the  synchronous  method  is 
advantageous  for  a system  where  there  are  a large  number  of  state  variables 
to  update,  and  the  asynchronous  method  is  favored  where  the  average 
event  length  is  great  (p.  126,  127,  Ref.  1).  The  Stanford  Research 
Institute  (SKI)  Air  Traffic  Flow  (ATF)  model  is  a synchronous  model 
in  which  the  simulation  progresses  in  uniform  time  steps. 

The  ATF  model  is  also  a "flow  rate"  model  instead  ;f  an 
"aircraft-following"  model.  There  are  three  primary  reasons  for  the 
selection  of  a "rate"  model: 
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• The  potential  size  of  the  geographical  area  (in  terms 
of  centers,  sectors,  and  routes)  that  the  model  was 
designed  to  serve,  find  the  potential  quantity  of  air- 
craft that  could  be  present  in  the  network  at  one  time 
would  render  an  aircraft-following  model  uneconomical 
and  infeasible  to  operate. 

• The  main  purpose  of  the  ATF  simulation  is  the  analysis 
of  ATC  productivity  and  capacity.  The  input  parameters 
governing  these  measures  are  flow-rate  oriented  (e.g., 
RECEP,  Workpace  and  Work  Activity,  Voice  Channel  Utiliza- 
tion) . 

• A "rate"  model  has  the  advantage  of  snapping  multivariate 

entities  (aircraft  identification,  velocity,  itinerary, 
times,  etc.)  into  a single  parameter:  flow  rate.  From 

an  analyst  point  of  view,  the  manipulation  of  the  model 
control  variables  is  made  easy  by  only  having  to  scale 
the  flow  rate  or  its  associated  variables  rather  than 
developing  aircraft  inventory  lists. 

The  selection  of  the  synchronous -time  progression  for  the  ATF 
model  is  based  mainly  on  the  aircraft  flow  behavior.  The  air  traffic 
flow  rate  tends  to  form  a high-density  stream  rather  than  sparcely 
placed  events,  therefore,  it  is  more  aligned  with  a synchronous  model 
than  an  event-step  model. 


1.2  THE  HEED  FOR  MODELING  I"  AIR  TRAFFIC  CONTROL  PRODUCTIVITY 
ANALYSIS 

1.2.1  Advantages  of  Using  Models  Vs.  Actual  System  Experiments 

It  is  a commonly  held  belief  that  actual  system  experiments 
are  superior  to  computer  modeling  because  the  former  method  is  more 
realistic,  therefore,  more  reliable.  This  belief  may  be  true  to  a 
certain  extent,  i.e.,  actual  system  experiments  are  desirable  as  long 
as  they  are  economically  and  operationally  feasible.  There  are  situa- 
tions in  which  an  assumed  ATC  system  cannot  be  satisfactorily  reproduced 


In  a current  operational  environment.  Examples  are:  (1)  The  system 

to  be  modeled  has  a much  higher  traffic  volume  than  tK:  current  operation; 
(2)  The  safety  of  a new  operation  has  not  been  verified;  (3)  A different 
sector  organization  is  to  be  tested;  or  (A)  A future  automation  package 
that  yet  has  to  be  produced  must  be  evaluated.  In  these  cases  it  is 
desirable  to  model  a (future)  system  in  question  with  computer  Simula* 
tion.  Although  these  systems  can  be  simulated  in  real  time  it  is  often 
much  less  expensive  ar.d  quicker  to  perform  them  in  fast  time  provided 
that  the  controller's  tole  can  be  adequately  modeled.  The  Air  Traffic 
Flow  model  is  designed  with  this  purpose  in  mind.  The  advantage  of 
using  the  ATF  model  rather  than  real-world  system  experiments  is  sum- 
marized in  the  following  two  situations: 

• To  project  from  one  current  system  to  another — Examples 


of  this  would  be  the  modeling  of  increased  (or  decreased) 
traffic  demand  on  an  existing  system  (to  scale  up  cr 
down);  the  testing  of  a modified  sector  organization;  or 
the  evaluation  of  a new  congestion-relief  strategy  that 
has  yet  to  be  proven  prior  to  actual  field  implementation. 
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situation  mainly  applies  to  the  evaluation  of  future 
automation  proposals,  for  example,  automatic  data  handling, 
conflict  probe,  and  control-by-exception,  etc*  These 
studies  would  require  some  changes  in  sector  workload 
weighting  computations  as  well  as  traffic -demand  param- 
eters. The  SRI  studies  performed  at  Los  Angeles  and 
Atlanta  Centers  2,  3 are  primarily  of  this  type. 


Real-time  simulation  with  active  participation  by  air  traffic  controllers 
can  sometimes  be  used  to  model  ATC  functions  that  are  not  currently 
installed.  They  are  usually  performed  in  the  FAA  by  the  National 
Aviation  Facility  Experimental  Center  (NAFEC)  at  the  Digital  Simula- 
tion Facility  (DSF)  or  the  Terminal  Automation  Test  Facility  (TATF). 
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1.2.2  History  and  Background 


The  work  described  here  addresses  the  methodologies  to  analyze 
enroute  air  traffic  control  operations.  Although  alternative  models  of 
control  operations  are  described,  the  majority  of  this  work  is  based  on 
models  of  sector  control  team  workload  requirements.  The  models  include 
the  Relative  Capacity  Estimating  Process  (RECEP),  which  relates  control- 
ler workload  to  sector'  traffic  capacities,  and  the  Air  Traffic  Flow 
network-simulation  model,  which  assess  traffic  capacity  and  delay  in  a 
multisector  environment.  Both  models  were  developed  previously  by  SRI 
for  the  FAA.2-7 

RECEP  was  initially  developed  as  part  of  an  SRI  effort  di- 
rected to  assessing  the  capacity  implications  of  controller  judgmental 
factors  and  decision  processes  for  several  levels  of  automation.4* £*' 

This  initial  RECEP  formulation  consisted  of  two  parts.  The  first  part 
relates  quantitative  stateaents  of  sector  physical  configurations, 
traffic  flows  and  mixes,  to  an  automation  application  as  it  bears  on 
control  decision-making  and  to  the  frequencies  of  occurrence  of  various 
types  of  ATC  events  (e.g.,  crossing  conflicts,  overtakes,  altitude  con- 
flicts, priority  decisions).  The  second  part  of  RECEP  attaches  a 
"decision-making  time"  tc  each  such  ATC  event,  based  on  the  minimum 
values  measured  for  these  times.  The  advantages  of  using  minimum  per- 
formance times  arc:  (l)  to  avoid  the  necessity  of  a detailed  and 

extremely  difficult  accounting  of  overlapping  task  situations,  and  (2) 
that  the  minimum  performance  time  is  more  likely  to  be  invariant  over 
time  and  location,  therefore,  is  a much  more  reliable  measure  chan 
average  or  actual  times.  RECEP  then  compares  aggregate  decision-making 
time  requirements  to  a threshold  representing  time  available  to  generate 
relative  capacity  estimates  for  alternative  automation  specifications. 

The  values  and  parameters  that  define  the  frequency-of-occurrence  re- 
lationships and  decision-making  times  were  determined  using  a measurement 


6 


technique  developed  by  SRI  that  includes  observation  of  sector  operations, 
followed  by  structured  controller  interviews  using  a video  playback  of 
the  observed  sector  operations. 

Subsequent  SRI  study  efforts  addressed  specific  automation 
elements  of  the  FAA's  Upgraded  Third  Generation  (UG3RD)  ATC  program, 
which  required  a finer  description  of  controller  activities  than  that 
of  the  initial  RECEP  formulation.8* 3* 7 Therefore,  a revised  RECEP 
model  was  developed  that  differentiated  individual  task  activities  so 
that  the  impact  of  each  automation  proposal  on  controller  operations 
could  be  assessed.  The  revised  RECEP  model  is  described  in  detail  in 
Section  IV  of  this  report. 

The  ATF  model  was  developed  in  parallel  with  the  RECEP  re- 
vision and  was  designed  to  assess  the  impact  of  automation  on  a multi- 
sector environment.  ATF  is  a computerized  device  to  translate  the 
RECEP  capacity  estimates  for  individual  sectors  into  multisector  traffic 
constraints.  The  model  assesses  the  degree  to  which  sector  traffic 
flow  rates  are  constrained  by  individual  sector  capacities  and  estimates 
aircraft  delay  for  the  multisector  environment. 

The  initial  RECEP  technique  was  applied  to  some  16  sectors 
in  enroute  and  terminal  facilities.  Four  enroute  sectors — first  one 
at  the  Oakland  Air  Route  Traffic  Control  Center  (ARTCC),  and  then  three 
at  the  Chicago  ARTCC — were  modeled  prior  to  implementation  of  the  Na- 
tional Aviation  System  (NAS)  Stage  A system.  Twelve  terminal  sectors- - 
four  each  at  the  Oakland  Bay,  Washington  National,  and  Boston  Logan 
Terminal  Rada-  Approach  Control  (TRACON)--were  modeled  subsequently  as 
Automated  Radar  Terminal  System  (ARTS)  III  operatives.  The  revised 
RECEP  model  was  developed  and  applied  to  four  enroute  sectors  at  the 
Los  Angeles  ARTCC,  and  later  applied  to  seven  enroute  sectors  at 
the  Atlanta  ARTCC.3*7 
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In  all  cases,  the  resulting  RECEP  sector  capacity  estimates 
were  consistent  with  those  made  by  the  facility  personnel  as  well  as 
with  the  Busy  Day  Reports.  Although  these  results  may  not  be  considered 
a formal  validation  of  the  RECEP  model,  they  do  indicate  it  to  be  a 
reasonable  representation  of  concrol  operations. 

The  ATF  model  was  applied  to  two  selected  multisector  regions, 
one  at  the  Los  Angeles  ARTCC  and  the  other  at  the  Atlanta  ARTCC.  Both 
model  applications  used  the  RECEP-analyzed  sectors  as  a basis  for  study 
although  additional  sectors  were  included.  The  ATF  network  model, 
which  is  relatively  new  and  not  previously  used  as  extensively  as  RECEP, 
has  not  been  subject  to  formal  validation. 


Since  these  applications  of  the  Air  Traffic  Flow  model,  the 
model  has  been  modified  in  some  minor  respects.  These  changes  have 
been  primarily  for  convenience.  Newer  output  has  not  significantly 
changed  from  the  older  model.  Throughout  the  remainder  of  this  discus- 
sion we  will  describe  the  newer  ATF  model  and  the  revised  RECEP. 

1.2.3  Application  Areas 

RECEP  and  ATF  were  developed  specifically  as  tools  to  evaluate 
the  impact  of  automation  on  ATC  operations.  SRI's  past  use  of  the 
models  was  to  measure  the  traffic-handling  capabilities  of  various  auto- 
mation alternatives  and  to  compare  manning  requirements  at  various  traffic 
projections.  This  technique  enabled  the  quantification  of  the  produc- 
tivity of  alternative  ATC  systems. 
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Although  ATF/RECEP  was  designed  to  evaluate  postulated  future 
operations,  the  models  may  be  used  to  analyze  more  near-term  aspects 
of  ATC  system  planning.  Such  applications  include  the  analyses  of  opera- 
tional and  pro:edural  options  for  the  current  system  and  resectorization 
alternatives.  These  areas  of  interest  relate  to  the  adjustments  being 


made  by  facility  personnel  to  keep  their  operations  consistent  with 
changes  in  traffic  demand.  The  emphasis  here  is  on  the  use  of  RECEP 
to  describe  changes  to  control  procedures;  it  does  not  relate  to  the 
hardware/ software  alternations  associated  with  automation. 
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2.  SUMMARY  DESCRIPTION  OF  RECEP  AND  THE  AIR  TRAFFIC  FLOW  MODEL 


2.1  THE  RELATIVE  CAPACITY  ESTIMATING  PROCESS  (RECEP)  SUMMARY 

The  RECEP  modeling  approach  estimates  the  traffic  handling  capa- 
bilities of  an  individual  sector  by  encoding  the  controller  work  associ- 
ated with  the  sector's  operational  requirements.  RECEP  models  are 
mathematical  representations  of  the  routine,  surveillance,  and  conflict 
processing  workload  requirements  of  a sector  team.  Routine  work  tasks 
include  air/ ground  (A/G)  voice  communications,  flight  data  processing 
(FDP)  and  radar  dati  processing  (RDP)  manual  data  entry/display  opera- 
tions, flight-strip  data  processing,  intersector  interphone  voice  com- 
munications, and  intrasector  direct  (face-to-face)  voice  communications. 
Surveillance  work  is  visual  observation  of  radar-derived  aircraft  situ- 
ation data  on  a plan  view  display  (PVD).  Conflict  processing  work  in- 
cludes potential  conflict  recognition,  assessment,  and  resolution 
decision  making  and  A/G  voice  communications. 

A sector  RECEP  model  is  an  additive  recoi.struction  of  the  workload 
requirements,  measured  in  time-based  units  (e.g.,  man-minutes  of  work 
which  include  minimum  task  performance  and  are  associated  with  the 
sector's  control  operations.  The  routine,  surveillance,  and  conflict 
processing  workload  requirements  are  formulated  as  functions  of  traffic 
flow  rate  and  sector  transit  time.  The  aggregate  work  times  (e.g.,  man- 
in'  a of  work  per  hour)  resulting  from  various  rates  of  traffic  flow  (e.g., 
aircraft  per  hour)  through  a sector  are  compared  with  a prespecified 
workload  limit  to  obtain  sector  team  traffic  flow  capacity  estimates. 

RECEP  is  used  to  estimate  the  traffic  capacities  of  individual 

sectors  under  alternative  operating  modes.  The  capacity  estimates 

correspond  to  baseline  and  enhanced  system  operations,  as  well  as 
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feasible  sector  manning  strategies  (i.e,  one-man,  two-man,  or  three- 
man  sector  teams).  RECEP  is  also  used  as  the  basis  for  first-order 
estimation  of  the  capacity  effects  of  sector  splitting.  The  capability 
to  model  alternative  sector  manning  strategies  and  sectorization  de- 
signs (based  on  sector  splitting)  enables  us  to  quantify  staffing  al- 
ternatives for  each  system  and  is  important  for  productivity  analysis. 


2.1.1  Baseline  System  Modelin 


The  RECEP  models  of  baseline  system  sector  team  operations 
are  constructed  using  field  observations  and  related  data  collections. 
These  models  represent  the  current  controller  workload  requirements 
(i.e.,  routine,  surveillance,  and  conflict  processing)  associated  with 
the  current  manning  characteristics  of  each  sector  under  analysis; 
therefore,  these  models  describe  sector  team  traffic  capacities  under 
current  operating  conditions. 

To  allow  for  baseline  system  staffing  increases  in  response 
to  future  traffic  increases,  we  adjust  the  workload  structure  of  the 
current  baseline  system  RECEP  BK>dels  to  represent  realistic  sector 
team  manning  alternatives  (e.*.,  expand  from  two-man  to  three-man 
teams)  and  resectorizations  (e.g.,  split  one  sector  into  two  sectors 
and  provide  additional  controllers).  The  procedure  enables  restructur- 
ing in  detail  of  the  controller  tasks  described  in  the  baseline  RECEP 
models. 

Modeling  sector  splits  is  less  refined  because  route  restructur- 
ing effects  on  sector  workload  requirements  are  not  known  and  must  be 
judgmentally  determined.  Therefore,  a rough  approximation  is  obtained 
of  the  workload  and  capacity  relationships  associated  with  the  distribu- 
tion of  workload  among  the  sectors  formed  by  splitting.  A first-order 
sector  splitting  model  developed  by  SRI7  takes  into  consideration  the 
reallocation  of  conflict  processing  work  and  the  additional  routine 
work  introduced  by  new  sector  boundaries.  This  model  was  used  to  study 


Los  Angeles  Center  sector  splits.  In  subsequent  productivity  analysis 
work  for  the  Atlanta  Center,  ve  have  used  the  Los  Angeles  Center  results 
as  analogies  from  which  we  estimated  the  percentage  increrse  in  traffic 
capacities  resulting  from  splitting  sectors.  A more  detailed  descrip- 
tion is  given  in  Section  VI-A. 

The  RECEP  models  of  current  operations,  alternative  sector 
manning  strategies,  and  resectorizations  obtain  traffic  capacity  esti- 
mates for  each  baseline  sector  for  each  operating  configuration.  This 
set  of  RECEP  models  therefore  describes  the  sector  capacity  effects 
resulting  from  sector  staffing  changes  for  the  baseline  system. 

2.1.2  Enhancement  Systems  Modeling 

We  follow  the  same  procedure  as  that  for  the  baseline  system 
to  define  RECEP  models  for  enhanced  sector  operations  postulated  under 
alternative  manning  and  sectorization  options.  We  first  construct 
RECEP  workload  requirements  for  each  sector  using  a sector  manning 
strategy  analogous  to  the  current  one.  We  construct  the  workload 
requirements  by  adjusting  the  baseline  system's  routine  and  conflict 
processing  tasks  to  conform  to  an  enhancement  of  automation's  operating 
characteristics.  (Surveillance  adjustments  could  also  be  made  if 
appropriate  although  we  have  found  that  the  measured  values  have  not 
changed  from  those  in  past  analysis  work).  These  adjustments  encode 
the  assumptions  we  make  as  to  how  an  enhancement  item  would  be  imple- 
mented in  an  operational  control  environment.  We  then  proceed,  as 
described  for  the  baseline  case,  to  model  realistic  sector  manning 
strategies  and  resectorization  alternatives.  The  resulting  RECEP  models 
obtain  sector  capacities  corresponding  to  the  alternative  sector  staffing 
levels  for  each  enhanced  system  under  evaluation. 


2.2  THE  AIR  TRAFFIC  FLOW  MODEL  (ATF) 

ATF  is  a computerized  network  simulation  of  multisector  air  traffic 
route  flows  iu  which  the  route  network  is  partitioned  into  control 
sectors.  That  is,  the  route  network  is  represented  by  a connected 
series  of  route  segments  (arcs),  where  each  segment  represents  a directed 
flow  of  aircraft  tnrough  one  sector.  Each  sector  contains  a set  of 
route  segments  each  of  which  is  connected  at  eigher  end  to  route  segments 
of  adjacent  sectors;  the  first  and  last  route  segments  connect  to  sector 
boundaries.  In  the  event  that  two  or  more  separate  route  segments  are 
merged  into  or  demerged  from  a single  route  within  a sector,  for  the 
purpose  of  proper  accounting,  these  route  segments  are  defined  as  sep- 
arate  routes.  The  connected  route  segments  enables  ATF  to  trace,  over 
time,  aggregate  traffic  flows  from  sector  to  sector,  and  thereby  repre- 
sent multisector  traffic  activity  without  actually  tracking  individual 
aircraft  trajectories  (an  attribute  that  reduces  calculation  requirements 
and  computer  run  costs). 

Because  the  route  segments  are  partitioned  into  sectors,  the  number 
of,  aircraft  on  each  route  segment  during  some  small  time  increment 
(e.g,  one-minute)  provides  a convenient  means  to  calculate  readily  the 
number  of  aircraft  through  each  sector.  These  data,  together  with 
RECEP-based  sector  workload  capacity  relationships,  are  used  on  ATF 
to  determine  the  degree  of  traffic  saturation  of  each  sector  team.  The 
ATF  model  operation  loads  traffic  onto  the  aniltlsector  network,  moves 
traffic  from  sector  to  sector  at  successive  time  increments,  and  searches 
for  sector  team  traffic  saturation  conditions.  When  imminent  saturation 
situations  are  found,  an  ATF  load-balancing  algorithm  selectively  delays 
aircraft  to  resolve  the  traffic  congestion  conditions.  In  essence, 
the  load-balancing  algorithm  distributes  workload  to  upstream  sectors 
to  prevent  a downstream  sector  team  work  overload.  ATF  traces  the 
propagation  of  traffic  congestion  and  delays  through  the  network 
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overtime  and  calculates  aircraft  average  delay  statistics.  In  addition, 
the  number  of  aircraft  and  the  workload  values  are  also  recorded. 

We  use  ^TF  to  estimate  the  average  aircraft  delay  experienced 
during  some  i.tme  interval  of  Interest  (e.g.,  2-hour,  3-hour,  or  8-hour 
intervals  as  ^ay  be  chosen  by  the  analysts)  in  a selected  multisector 
environment  for  a range  of  traffic-loading  projections.  The  multisector 
environment  is  defined  by  specifying  the  route  network  structure  and 
control  operation,  baseline  or  enhanced.  The  control  operation  is  rep- 
resented by  the  RECEP-based  workload-capacity  relationships  deti  rained 
for  each  feasifcile  combination  of  baseline  or  enhanced  system,  sector 
manning  strategy,  and  sectorization  configuration.  For  the  purpose 
of  productivity  analysis,  we  determine  and  compare  the  average  aircraft 
delays  corresponding  to  the  various  control  operations  while  holding 
the  route  structure  fixed.  The  procedure  isolates  the  delay  effects 
of  automation  implementation  from  those  effects  relating  to  route  structure. 


2.3  RELATIONSHIP  BETWEEN  RECEP  AND  ATF 

Although  RECEP  and  ATF  are  two  separate  systems,  their  joint  use 
has  often  given  the  impression  that  they  must  go  together,  or  that  RECEP 
is  an  integral  part  of  ATF.  It  can  be  viewed  that  RECEP  is  an  external 
input  process  to  AT?  when  they  are  used  jointly  in  a multisector  KiC 
productivity  analysis.  However,  RECEP  can  also  be  used  as  a stand-alone 
system  when  single-sector  workload  and  capacity  are  of  primary  interest. 
Also,  the  ATF  model  may  be  used  independently  of  RE^EP  if  other  means 
arc  available  to  generate  workload  coefficients  and  sector-capacity 
Inputs. 

In  general,  the  input  parameters  that  RECEP  supplies  to  the  ATF 
model  arc  the  workload  coefficients  that  are  results  of  routine -events, 
surveillance,  and  potential  conflict-events  workload  estimates,  and 


surveillance,  and  potential  conflict-events  workload  estimates,  and 
the  sector  capacity  estimates.  The  rest  of  the  ATF  input  parameters, 
such  as  aircraft  flow  rates  along  routes,  route  structure,  and  congestion- 
relief  schemes,  are  not  parts  of  RECE?. 


16 


3.  OTHER  RELATED  MEASURES  AND  MODELS 


i 
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3.1  WORKPACE  AND  WORK  ACTIVITY  MEASURES 

3.1.1  Description  of  Workpace  and  Work  Activity 

Work  activity  (WA)  measurement  is  a technique  used  by  the  FAA 
to  perform  on-site  observation  of  controllers  manual  workload  as  it  is 
divided  into  over  25  basic  indicators  (see  Table  1 for  more  details). 

The  observation  is  usually  recorded  at  5-minute  intervals  at  selected 
sectors  and  centers  over  a specified  period  (e.g.,  one  or  two  hours). 

In  addition  to  the  controller's  basic  workload  activities,  the  sampling 
also  includes  the  following  traffic- loading  paraafeters: 

• Peak  Aircraft — The  highest  number  of  aircraft  under  the 
sector's  jurisdiction  at  any  one  time  within  the  observa- 
tion interval. 

• Sector  Flight  Time- -The  average  time  (in  minutes)  that 
an  aircraft  would  be  under  the  jurisdiction  of  a 
sector . 

• Aircraft  Handled — The  equivalent  nusAer  of  aircraft 
handled  during  the  observation  interval  obtained  by 
dividing  the  aircraft  minutes  by  Sector  Flight  Tlsie. 

Independent  of  WA  measureswnt  is  a rating  function — Work  pace 
(WP)— that  is  an  interger  function  ranging  in  seven  values  from  "very 
light"  to  "very  heavy"  (see  Table  2 for  more  details).  A single-digit 
rating  is  given  by  a peer  observer  for  each  5-minute  observation  interval 
to  describe  the  intensity  of  the  workload  imposed  upon  the  controller  as 
a result  of  traffic  volume  and  complexity. 

The  result  of  these  observations  (both  WA  and  WP)  are  kept 
on  computer  magnetic  tapes;  therefore,  historical  data  can  be  accessed 
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TABLE  1 


ENROUTE/TERMIHAL  WORK  ACTIVITY  CODES 


| Enroute 
I Code 


Terminal 

Code 


Workload  Indicator 


Activity 


AC 

AV 

SC 

SV 

VC 

oc 

AD 

B 

HO 

HI 

CO 

Cl 

IC 

VH 

VO 

VR 

VL 

VD 

Q 

FS 

SB 

AE 

DL 

HS 

SY 


no 

131 

140 

141 
100 
100 
400 

CHF6.RHF 

CHS&RHS 

CF 

CS,CCI, INT 
INT 

CK4&RHH 
CC,  CSM 
CR 
CH 

CFD 

QL,RGH,KRH,DU,KC 

FS 

AE 

IX 


Altitude  Control 
Altitude  Verification 
Speed  Control 
Speed  Verification 
Vector  for  Control 
Other  Control 
Advisory 
Beacon 

Han doff  Outside  ARTCC 
Handoff  Inside  ARTCC 
Coordination  Outside  ARTCC 
Coordination  Inside  ARTCC 
Issue  Clearances 
Verbal  Handoff 

Verbal  Coordination  Outside  Sector 

Verbal  Coordination  With  "R"  Man 

Verbal  Coordination  With  "H"  Man 
(Manual  Only) 

Verbal  Coordination  With  "D"  Man 

C.U.E.  Entries 

Flight  Strip  Activity 

Shrimp  Boat  Activity  (manual  system 

Adjust  Equipment 

Data  Lookup,  Charts,  Maps,  etc. 

Hand  Signal 
Standby 


only) 


Radio 
Radio 
Radio 
Radio 
Radio 
Radio 
Radio 
Radio 
Interphone 
Interphone 
Interphone 
Interphone 
Interphone 
Verbal 
Verbal 
Verbal 
Vernal 

Verbal 

Manual 

Manual 

Manual 

Manual 

Manual 

Visual 

Standby 


TABLE  2 
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WORKPACE  DEFINITIONS 


• Very  Light  Workload  (VL).  A "VL"  rating  should  be  assigned  when 
the  Workpace  level  is  so  low  that  relatively  little  attention  has 
to  be  paid  to  the  position  of  operation.  Minimal  exertion  is  re- 
quired. 

• Light  Workload  (L).  An  "L"  rating  should  be  assigned  when  the  Work- 
pace  is  such  that  more  than  minimal  exertion  is  required,  but  the 
complexity  of  situations  is  such  to  only  engage  the  controller's 
complete  attention  periodically.  There  arc  no  complex  control  situ- 
ations. 

• Average  Workload  (A).  An  "A"  should  be  assigned  when  the  situation 
complexity  requires  almost  full-time  attention  of  the  controller. 

The  workload  is  evenly  distributed  and  places  no  unusual  demand 
upon  the  controller.  This  pace  could  be  maintained  up  to  an  8-hour 
period  with  normal  relief. 

- Gradient.  A-  should  be  assigned  when  significantly  less  than 
full  attentiveness  is  required  at  the  position;  the  demands  placed 
upon  the  controller  are  slightly  less  than  one  could  expect  at 
average.  Infrequent  periods  of  inactivity  occur. 

4-  Gradient.  A+  should  be  assigned  when  the  demands  are  slightly 
greater  than  A.  Rare  periods  of  Inactivity,  full  attentiveness  to 
the  position  is  required.  A controller  could  be  expected  to  work 
at  this  pace  up  to  six  hours  with  normal  relief. 

• Heav  ' Workload  (H).  An  ”H"  rating  should  be  assigned  when  the  com- 
plexity and  exertion  required  to  cope  with  the  situation  necessitate 
rapid  decisions;  there  is  constant  operational  activity.  Demands 
placed  upon  the  controller  exceed  those  of  a normal  pace.  A con- 
troller could  be  expected  to  securely  deal  with  this  level  of  work 
for  up  to  3 hours. 

• Very  Heavy  (VH).  A ,tVH"  should  be  assigned  when  there  is  continuous, 
laborious  activity;  superior  exertion  is  required  and  the  rapidity 
of  response  and  thinking  processes  are  critical.  There  are  delays 

in  acknowledging  demands  placed  upon  the  position.  A controller 
would  be  "pushed1’  to  maintain  this  pace  for  l heur. 
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to  perform  "before-and-after"  comparisons  of  parameter  changes.  The 
format  of  the  tape  record  is  given  in  Appendix  A.  An  automatic  maximum 
hourly  WP  search  program  has  been  developed  by  the  Transportation  Sys- 
tems Center  that  can  rapidly  search  and  identify  from  the  WA/WP  tapes 
those  time  periods  and  sectors  that  have  experienced  maximum  workload. 

Detailed  printout  is  also  given  by  this  program  for  analysis  purposes. 

See  Appendix  B for  more  details. 

3.1.2  Comparlfon  of  Data  Elements  Between  RECEP  and  Work  Activity 

Because  the  development  of  RECEP  and  WP/WP  techniques  were 
independent  of  each  other,  their  data  elements,  data  classification 
schemes,  data  resolutions,  and  field  test  techniques  are  understandably 
different.  However,  there  are  enough  similarities  between  the  two  tech- 
niques that  would  warrant  a closer  examination  for  constructing  an 
approximating  function.  Each  technique  involves  a two-dimensional 
classification  scheme: 

WA RECEP 

Row  Elements:  Workload  Indicator  Control  Events 

Column  Elements:  Activities  Control  Tasks 

The  RECEP  classification  matrix  contains  approximately  90  nonzero 
entries,  whereas,  WA  matrix  contains  approximately  33  nonzero  entries. 

Because  of  the  difference  in  their  methods  of  classification  and  aggre- 
gation, the  memberships  of  the  two  systems  do  not  have  a one-to-one 
match.  In  fact,  because  the  number  of  nonzero  entries  has  a three-to- 
one  ratio,  the  mapping  function  is  essentially  many-to-one  (from  RECEP 
to  WA).  Although  a precise  mapping  function  may  be  difficult  to  es- 
tablish because  the  definitions  and  resolutions  of  the  data  eleamnts 
are  not  always  compatible  between  the  two  systems,  an  attempt  is  made  in 
Appendix  C to  show  some  equivalence  relationships.  To  understand  the  full 
implications  of  Appendix  C,  the  reader  is  advised  to  also  read  Section  IV. 

Description  of  the  Relative  Capacity  Estimating  Process. 

20 

i 

1 

J 

J 


It  would  appear  from  Appendix  C that  the  correspondence  be- 
tween elements  of  RECEP  and  UA  are  aggregated  and  with  much  overlapping. 
The  only  possible  agreement  between  the  two  systems  would  seem  to  be 
in  the  column  totals  and  grand  totals.  The  following  is  a list  of 
column  titles  of  the  two  systems  that  roughly  correspond  to  each  other: 


RECEP WA 


1. 

A/G  Communication 

1. 

Aiv/Ground/Air 

2. 

FDP/RDP  Operation 

2. 

’.anual-Keypack 

3. 

Interphone  Coe  ication 

3. 

Interphone 

4. 

Plight  Strip  irocessing 

4. 

Manual-Flight  Strip  Activity 

5. 

Direct  Voice  Communication 

5. 

Verbal  (or  Oral) 

3.1.3  Major  Differences  Between  RECEP  and  Work  Activity  Measures 

This  section  gives  a description  of  the  differences  between 
RECEP  and  work  activity  measures  in  three  major  categories— the  develop- 
ment of  the  conflict  measures;  standard  times  vs.  actual  times;  and 
data  resolution. 

3. 1.3.1  The  Development  of  Conflict  Event  Workload  Measures 

Although  the  radio  transmission  activities  relating  to 

contuct  resolution,  sequencing,  and  in-trail  spacing  (VC)  are  monitored 

by  the  WA  technique,  there  are  no  procedures  in  the  WA/WP  technique 

with  which  to  measure  decision-making  times  imposed  by  potential  ccr- 

* 

flict  and  overtake  events.  It  is  to  be  noted,  however,  that  conflict 
and  overtake  resolution  workload  of  a sector  is  isq>lied  in  the  WP  rating 
even  though  the  independent  variables  (i.e.,  conflict  routing  parameters) 
arc  not  explicitly  measured. 


The  portion  of  air/ground  communication  attributed  to  potential  conflict 
workload  is  relatively  small;  therefore,  in  a first-order  approximation 
the  lack  of  conflict  procedures  in  WA/VP  will  not  significantly  affect 
the  gross  agreement  on  the  two  measures  in  routine  workloads. 
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A procedure  based  on  a RECCP-WA/WP  combination  may  be 
feasible  in  which  the  routine-event  workload  would  be  measured  with  WA 
technique  but  RECEP  would  still  be  required  to  compute  conflict-event 
workload  weightings. 

¥ 

3. 1.3. 2 Standard  Times  Vs,  Actual  Times 

Perhaps  one  of  the  major  differences  in  the  RECEP  and  WA 
techniques  is  the  concept  of  "standard  time"  (used  by  RECEP)  vs.  "actual 
time"  (used  by  WA).  The  primary  design  purpose  of  RECEP  is  for  pre- 
dicting controllers*  future  productivity  due  to  assumed  changes  rather 
than  evaluating  current  performance;  therefore,  the  minimum  times  de- 
veloped for  RECEP  are  intended  to  be  invariant  over  time  end  location. 

It  has  been  recognized  that  human  performance  time  on  a given  task 
usually  varies  between  individuals  and  even  within  the  same  Individual. 

Unless  this  variance  is  minimized,  task  performance  time  is  not  an 
effective  tool  for  comparing  different  existing  systems  or  predicting 
the  effect  of  future  automation.  For  this  reason,  the  iasic  RECEP  * 

workload  measures  (task  times)  are  defined  as  "minimum  times’*  which 
imply  that  the  ATC  tasks  are  described  by  a set  of  irreducible  numbers 
and  that  the  only  time  these  numbers  may  be  modified  is  when  the  opera- 
tional characteristics  of-  the  tasks  are  changed. 

Cn  the  other  hand,  the  WA/WP  technique  is  designed  for 
comparing  "before-and-after"  effects  of  system  changes  pertinent  to 
controllers*  productivity.  The  task  time  measures  are  based  on  actual 
times  as  recorded  during  field  observation  over  a sampled  period. 

This  method  is  especially  effective  when  the  before-and-after  study 
is  conducted  for  the  same  center  with  the  same  group  of  controllers. 

Because  ATF/RECEP  has  been  used  in  the  past  mainly  for  forecasting 
future  productivity  changes  due  to  automation  and  the  WA  technique  has 
been  primarily  used  for  measuring  the  actual  productivity  increase  (or 


decrease)  after  the  automation  ia  installed,  WA/WP  can  be  effectively 
employed  as  a tool  to  verify  the  predictability  of  the  ATF/RECEP  model. 
This  verification  would  be  most  effective  if  minimum  rather  than  average 
task  times  were  used  in  the  computation  of  aggregate  WA  time 'frequency 
task  totals.  These  totals  could  then  be  compared  on  a column-by-column 
basis  with  the  RECEP  routine  workload  values. 


3. 1.3. 3 Data  Resolution  of  Event /Task  Elements 

Because  the  design  purpose  of  RECEP  is  the  ability  to 
compare  various  configurations  of  enhancement  packages  under  the  NAS 
Stage  A environment,  the  control-event  and  control-task  categories  are 
designed  to  reflect  the  most  elementary  building  blocks  to  describe 
controllers'  actions.  Consequently,  the  elements  in  a RECEP  minimum- 
time  data  matrix  can  be  considered  as  workload  "primitives"  which  are 
sensitive  to  the  effect  of  enhancements  to  controllers  tasks.  These 
primitives  are  then  used  to  construct  sets  of  controllers'  measures 
peculiar  to  a given  automation  operation.  It  is  for  this  reason  that 
the  RECEP  data  base  has  been  used  for  a wide  range  of  enhancement 
packages  with  practically  no  change  to  its  basic  matrix  structure  from 
one  site  to  another. 


3.2  VOICE  CHANNEL  UTILIZATION  (VCU) 
3.2.1  Introduction 


This  work  is  described  as  a simulation  model  for  ATC  com- 
munications based  upon  voice-recording  data  gathered  over  the  New  fork 
Center.  The  research  v«is  conducted  by  Princeton  University  and 
is  reported  in  four  \olumes: 


Volume  1: 


Contains  extensive  dictionaries  and  catalogs 
of  the  air/ ground  communication  message 
elements.0 


a 

i, 
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Volume  2:  Describes  initial  statistical  analyses  and  early 

simulations  of  single  sectors.9 

Volume  3:  Describes  the  construction,  validation,  and  initial 

exercises  of  the  General  Purpose  System  Simulation 
(GPSS)  model  of  controller  workload  which  is  based 
on  air/ground  communications  channel  loading.10 

Volume  4:  Reports  the  simulation  model  for  the  New  York  air 

traffic  control  communications,  the  validation  of 
the  model,  and  the  extension  of  the  model  to  other 
air/ground  communications  at  the  Houston  ARTCC.11 


3.2.2  General  Model  Description 

In  general,  the  Princeton  Model  is  structured  as  given  in 
Figure  1.  It  has  been  shown  by  the  designers  to  be  an  adequate  simula- 
tion of  VCU  and  aircraft  loading  operations  for  specific  New  York  sec- 
tors which  were  modeled.  In  addition,  preliminary  findings  reported 
in  Volume  4 indicate  that  the  model  is  valid  for  communications  simula- 
tion of  generalized  sector  types. 

The  model  requires  the  following  input  parameters: 

p,  the  aircraft  arrival  rate. 

p and  k,  the  parameters  of  the  number  of  intercommunication 
gaps  per  aircraft  distribution. 

a and  \,  the  parameters  of  the  transmission  length  distribu- 
tion. 

aQ  and  a^,  the  parameters  relating  the  CT  length  with  the 
number  of  CT  per  aircraft. 

The  output  of  the  model  can  be  categorized  as  follows: 

• Aircraft  loading,  nfc; 

• Channel  utilization,  Cfc; 

• Number  of  aircraft  in  queue  waiting  to  communicate,  Q^. 


Each  of  the  above  sector  responses  can  be  represented  by  a 


time  series: 


■Mill  til! 
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FIGURE  1 A GPSS  MODEL  FOR  VOICE  CHANNEL  UTILIZATION 
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• For  nt,  the  second-order  autoregressive  model 

» H + *l(nt-l  " ^ + ^2(nt-2  " ^ + at 

2 

where  0^  and  02  are  parameters,  at  ~ N(0,  a ) and  u 
is  the  expected  value  of  nt. 

• For  CU  (denoted  by  Ct),  the  first-order  autoregressive 
model* 


# **  ** 

The  symbols  0 and  02,  0^  and  02  denote  amplitudes  of  a Box-Jenkins 
second  order  autoregressive  model;  the  symbol  0f  also  denotes  the  am- 
plitude of  the  first-order  autoregressive  model.11  The  notation  at  ~ 
N(0,  o^)  is  a standard  expression  in  statistics  which  means  the  random 
variable  a^  is  normally  distributed  with  mean  0 and  variance  a^. 

25 


I 

} 

S 

5 

■5? 


i 


Ct  - 0 + 01(C^l  - 9)  + bfc 

* 9 

where  0^  is  a paramet-r,  bc  ~ N(0,  a*)  and  0 is  the 
expected  level  of  Ct. 

• For  Qt  (after  a negative  exponential  transformation,  de- 
noted by  at),  the  second-order  autoregressive  model? 

qfc  = U)  + 0l  (q{;_1  - W)  + 02  (qfc_2  - u>)  + Cfc 

★*  ★*  2 
where  0^  and  0£  are  parameters,  et  ~ N(0,  a**)  and  tu 

is  the  mean  level  of  q . 


3.2.3  Comparison  Betwee..  VCU  and  ATF/RECEP 

The  following  list  shows  the  general  comparison  between  the 
two  simulation  models  by  giving  descriptions  of  how  each  model  handles  a 
common  set  of  identified  model  elements: 


Model  Elements 


ATF/RECEP 


Network  representation 

Approximated  using 

Proposed  but  not 

l 

geographic  sector. 

presently  implemented 

route,  and  arc 

or  documented 

• 

representation. 

Traffic  flow 

Air-raft  arrival 

Aircraft  arrival  rate. 

representation 

rate. 

Capacity /workload 

Minimum  time  and 

VCU  provides  a linear 

measure 

event  frequency 

"workload"  function  up 

measurements  for 

to  857.  utilization, 

individual  sectors 

which  is  defined  as 

and  capacity 
estimates  for  each 
sector  based  upon 
field  measurements. 

capacity. 

$ **  ** 

The  symbols  0 and  0£,  0}  and  02  denote  amplitudes  of  a Box- Jenkins 
second  order  autoregressive  model;  the  symbol  0*  also  denotes  the  am- 
plitude of  the  first-order  autoregressive  model.11  The  notation  at  ~ 
N(0,  a^)  is  a standard  expression  in  statistics  which  means  the  random 
variable  at  is  normally  distributed  with  mean  0 and  variance  o^. 
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Model  Elements 


ATF/RECEP 


Multisector  measures 


Cumulative  aircraft 
delay.  Aircraft 
load.  Controller 
workload. 


No  system  measure. 
Sector  measure  of: 
Aircraft  load 
Voice  Channel  Utiliza- 
tion 

Queue  delays. 


Flow  control  schemes 


Two  possible  schemes 
presently  in  use. 


Not  applicable. 


Sensitivity  to  auto- 
mation configuration 


Reflected  through 
RECEP  event  fre- 
quency and  time 
calculation  adjust- 


ment. 


Any  automation  which 
affected  voice  communi- 
cations in  some  way 
could  probably  be  re- 
flected in  VCU  through 
the  message-content 
dictionary. 


It  can  be  seen  from  the  above  comparison  that  the  VCU 


simulation  could  be  compared  with  ATF  output  only  on  a sector-by-sector 


basis.  The  most  reasonable  output  available  for  direct  comparison 


would  be  aircraft  load.  A comparison  of  these  two  system  measures 


would  require  t'.r  ATF  to  provide  sector-by-sector  time  series  output. 


It  would  be  most  convenient  to  have  the  model  calculate  the  parameters 
required  to  construct  an  autoregressive  approximation  of  the  ATF  output.1* 


These  could  then  be  compared  with  the  VCU  output  for  the  same  time 
period.  Another  method  that  may  be  investigated  would  be  to  assume 


that  VCU  constituted  all  of  the  workload  at  each  sector.  This  method 


would  require  a comparison  of  VCU  average  time  and  frequency  products 
with  total  RECEP  workload  estimates.  However,  because  VCU  is  an  in- 
direct measure  of  workload  and  may  not  reflect  all  controller  activity, 
such  a comparison  may,  at  best,  only  indicate  proportionality  between 


the  results. 
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3.3  INDEX  OF  ORDERLINESS 

The  Index  of  Orderliness  Is  s system  perfocmsnce  measure  originally 
developed  as  a supplement  to  more  standard  performance  measures  during 
cost/benefit  studies  conducted  at  the  National  Aviation  Facilities 
Experimental  Center.13  The  index  was  designed  to  have  the  following 
attributes: 

• "Derived  from  objective  results  of  the  test  ... 

• Correlates  with  other  factors  which  independently  reflect 
safety,  capacity,  and  workload. 

• Statistically  manageable  ... 

• Have  operational  meaning  ... 

• Free  of  manipulation  by  test  subjects." 

The  remainder  of  this  section  contains  a brief  definition  of  the 
Index  of  Orderliness,  a description  of  the  filtering  and  formulations 
for  the  Index  as  given  by  Halverson,  and  finally  a proposal  for  compar- 
ing the  measure  to  RECEP  conflict-modeling  results. 


3.3.1  A Brief  Definition 


The  calculation  of  an  Index  of  Orderliness  for  any  airspace 
Involves  the  representation  of  the  closest  point  of  approach  of  ail 
aircraft  pairs  under  control  (a  conflict  prediction)  in  an  aggregate 
measurement  (a  threat-weighting  formula).  The  closest  point  of  approach 
for  a pair  of  aircraft  is  defined  as  the  expected  mLss  distance  (in 
' the  horizontal  plane)  of  the  pair  at  some  future  time.  The  miss  dis- 
tance depends  upon  several  factors  including  the  relative  velocity  of 
the  pair,  altitude,  separation,  accelerations  (including  turn  rates) 
and  the  intent  of  each  pilot.  For  computational  ease,  acceleration 
is  handled  through  approximations  of  the  accelerating  aircraft's 
true  airspeed  and  heading.  Altitude  separation  is  accounted  for  through 
filtering  and  is  also  included  in  some  of  the  threat-weighting  formulas. 
Pilot  intent  is  not  included. 
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3.3.2  Filtering  and  Weighting  Formulas 


The  number  of  calculations  of  closest  point  of  approach  for 
all  aircraft  in  an  airspace  at  frequent  intervals  can  be  large.  Thus, 
three  coarse  filters  are  applied  prior  to  calculation  of  closest  point 
of  approach  and  another  filter  is  applied  to  all  computed  closest  points 
of  approach  prior  to  inclusion  in  weighting  formulas. 

The  first  three  filters  inhibit  computation:  (1)  if  the 

difference  in  altitude  is  greater  than  a specific  minimum;  (2)  if 
the  altitude  separation  is  opening;  (3)  if  the  distance  between  aircraft 
is  greater  than  a minimum;  and  (4)  if  the  time  to  closest  point  of 
approach  (at  maximum  possible  closing  rate)  is  greater  than  a mi'  ^ua. 

The  final  filter  operates  on  the  distance,  altitude,  and  times 
to  closest  point  of  approach  and  excludes  those  not  meeting  minimum 
standards.  The  special  circumstances  presented  by  airports  are  also 
taken  into  account  by  this  filter. 


Several  weighting  formulas  for  the  index  have  been  proposed. 
The  Transportation  Systems  Center  (TSC)  Cambridge,  Massachusetts,  ex- 
plored the  following  six  formulations: 


_V  e ■ V60 
1 ^m2  + o.oi 


= S(Tm  + 5)  (M2  + 0. 


01) 


60 


jy ± 

3 “ (T„  + 5)  (M2  + 0.01)  (Dz  + 
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50) 


60 


100 


- AT 

^tm  [m*  + tm] 


r * & t 
[e  H.J 


«v 


f T t(M)  2 + (Dz)  2 + T ] 

M 3 900  £ 

60 


M ■ predicted  closest  point  of  approach  in  the  horizontal 
plane  (miles). 

Dz  ■ predicted  altitude  separation  (feet). 

Tm  * time  to  closest  point  of  approach  (seconds). 

AT  « problem  ticae- -matrix  entry  time. 

The  results  of  the  analysis  by  TSC  of  these  formulations  are  susmiarized 
in  the  Halverson  paper.13 


3.3.3  A Possible  Comparison 

It  has  been  proposed  that  the  Index  of  Orderliness  might  be  a 
useful  tool  to  provide  an  estimate  of  potential  conflict  events  as 
modeled  in  RECEP.  This  would  have  two  benefits.  The  first  Is  that 
it  would  provide  substantiating  evidence  regarding  the  validity  of  RECEP 
conflict  counts,  and  the  second  is  that  it  might  provide  a less-complex 
method  for  estimating  potential  conflict  frequencies. 

The  first  step  in  making  the  comparison  is  to  obtain  an 
approximation  of  the  closest  point  of  approach  calculations.  If  one 


inspects  the  formulations  for  the  index  given  previously  it  can  be 

seen  that  all  contain  a term  Thus  the  formulations  are  inversely 

proportional  to  the  area  of  a circle  with  radius  M.  This  can  be  (a» 

suggested  by  Halverson)  envisioned  as  a hazard  area  of  radius  M about 

an  aircraft.  Altitude  separation  terms  are  implied  through  filtering 

but  are  only  included  in  some  of  the  formulations.  One  can,  thus, 

hypothesize  that  there  may  be  a correlation  between  the  Index  and  the 

number  of  occurrences  of  aircraft  pairs  being  within  a cylindrical 

volume  of  radius  M and  height  D , centered  on  one  of  the  aircraft.  If 

z 

this  is  assumed  to  be  true,  then  the  Conflict  Alert  option  in  the 
data  analyses  and  reduction  tool  (DART)  printout  provides  a means  for 
a rough  comparison. 

This  Conflict  Alert  option  can  provide  a count  of  all  occur- 
rences of  aircraft  approaching  within  a cylindrical  volume  of  specific 
size  about  each  aircraft.  Although  this  approach  does  not  acccunt  for 
the  difference  in  heading  and  speed  between  the  pair  of  aircraft,  it 
appears  to  be  the  most  viable  in  terms  of  using  existing  tools  to  esti- 
mate potential  conflict  frequency  without  the  rigor  of  RECEP  conflict 
modeling,  or  calculating  closest  points  of  approach. 

The  procedure  for  experimenting  with  this  tool  would  be  as 
follows:  Select  four  to  six  sectors  in  a test  airspace  f*_r  RECEP 

modeling.  For  the  same  time  period  collect  SAR  tape  information.  Make 
several  runs  with  different  Conflict  Alert  sizes.  The  frequencies  re- 
sulting from  these  runs  would  then  be  compared  on  a one-to-one  basis 
with  the  RECEP  predictions  to  determine  which  distance  and  altitude 
limits  best  approximated  the  RECEP  formulation.  Ideally,  the  Conflict 
Alert  distance  and  altitudes  would  be  the  same  for  all  sectors  studied. 

Some  of  the  assumptions  made  to  conduct  the  experiment  may 
cause  problems.  The  first  pitfall  is  that  although  RECEP  accounts 
for  the  pilot's  intent  during  the  conflict  modeling,  the  Index  of 
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Orderliness  ^nd  Conflict  Alert  counts  do  not.  To  further  complicate 
the  problem,  the  Co>  >ict  Alert  proximity  count  does  not  account  for 
heading  or  speed  of  t.  pair  in  proximity.  The  result  is  that  two 
sectors  with  very  different  RECEP  conflict  workloads  could  have  exactly 
the  same  Index  of  Order Jiness  and  conflict  frequencies.  The  use  of 
Conflict  Alert  to  estimate  conflict  workload  will  require  considerable 
care  and  attention  to  the  operational  characteristics  of  the  sector. 

It  is  possible  that  procedures  to  handle  different  types  of  sectors 
can  be  developed. 


R 


4.  DESCRIPITON  OF  THE  RELATIVE  CAPACITY  ESTIMATING  PROCESS 

A RECEP  model  describes  the  workload  requirements  of  a sector  team 
based  r»n  observed  controller  activities  and  is,  therefore,  calibrated 
according  to  the  operational  characteristics  of  the  observed  or  baseline 
ATC  system.  In  this  section  we  discuss  the  calibration  of  RECEP  for 
baseline  NAS  Stage  A enroute  operations,  although,  except  for  tower 
activities,  the  calibration  would  also  apply  to  terminal  (TRACOft)  oper- 
ations. 

4.1  BACKGROUND 

RECEP  models  nf  selected  sectors  were  constructed  using  Los  Angeles 
Center  and  Atlanta  Center  observations.  The  basic  model  structure  was 
developed  as  part  of  the  Los  Angeles  Center  study  effort,  which  found 
that  a sector's  traffic  handling  capability  could  be  constrained  by 
various  members  of  the  control  team  depending  on  which  controller 
reached  his  workload  threshold  first.  To  account  for  the  situation,  a 
team  workload  and  a radar  (R)  controller  workload  model  forawlation  was 
developed  for  each  sector  to  represent  two-man  team  operations.  This 
team  includes  an  R controller  and  a data  (D)  controller,  and  was  the 
standard  manning  strategy  used  to  operate  a sector  (hiring  the  observa- 
tion sessions. 

The  team  model  was  based  on  empirical  data  obtained  from  the 
observations  and  calibrated  against  each  sector's  capacity  as  reported 
by  controllers.  The  team  odel  represents  the  combined  work  require- 
ment of  the  R end  D controllers.  Although  this  terns  model  was  useful 
for  analysing  observed  sector  operations  *t  the  Los  Angeles  Center, 
the  mode  by  itself  was  found  to  be  deficient  in  its  capability  to  model 
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alternative  operations  (i.e.,  three-man  teams,  sector  splitting,  and 
enhancement  systems)  where  the  R controller,  instead  of  the  D controller, 
performs  the  dominant  portion  of  the  team  work.  Therefore,  the  R-controller 
model  was  developed  as  a check  of  the  team  model  to  assure  that  tiie  R 
controller  alone  would  not  first  be  overloaded  with  work.  The  models 
were  constructed  such  that  the  team  model  determined  sector  capacity 
if  the  D controller  is  work  saturated  and  cannot  accept  more  work  from 
the  R controller;  the  R controller  model  determined  sector  capacity  If 
this  controller  is  work  overloaded.  Therefore,  both  models  woo’d  he 
needed  to  evaluate  the  capacity  of  a single  sector,  although  only  one 
may  be  critical. 

The  team  and  R-controller  sectoi  modeling  approach  was  used  also 
as  part  of  the  Atlanta  Center  study  and  proved  to  be  an  appropriate  means 
to  evaluate  sector  operations. 

U.l  DESCRIPTION 

The  team  model  developed  during  the  Los  Angeles  case  study  is  based 
on  data  measurements  of  observed  rout  in.-  and  contlict  processing  activities, 
and  is  used  to  estimate  sector  te  *m  workload  ti'ie  devoted  to  these 
activities  as  a function  of  traffic  flow  rat.-.  Setter  team  workload  time, 
W^,  measured  in  man-min/hr.  is  cniculited  usiar  an  additive  aodel  of 
work  components: 


W’ 

i 


Ik  X + (k7  + k » N"l/60 

* — 3 


where 

X is  the  number  of  aircraft/hr  through  tne  sector. 


k 


1 


is  the  tea-,  routine  work 

aircraft 


oad  wc- 


inc,  measured  in  man-s^-c/ 


* 

k.,  is  the  crossing  conflict  workload  weighting  Matured  In 
(man-sec/hr )/ (a ire raft /hr )^. 

k^  is  the  overtaking  conflict  workload  weighting  Matured  In 
(un*  tec/hr)/  (a  ircraft/nr) 

60  is  Che  factor  to  convert  man-sec/hr  of  work  to  man~mia/hr. 

The  corresponding  R controller  node  1 is  constructed  by  allocating 

portions  of  the  team's  routine  work  and  all  the  conflict  processing 

work  to  the  R controller  and  introducing  R controller  surveillance  work. 

The  surveillance  work  could  not  be  Matured  adequately  by  Mans  of 

direct  observation,  and,  therefore,  is.  not  included  in  the  teem  workload 

model.  However,  because  PVD  surveillance  is  an  important  R controller 

responsibility,  assumptions  regarding  surveillance  work  were  developed 

from  controller  interviews.  R controller  workload  time,  W measured 

r 

in  man-min/hr,  is  calculated  using  the  additive  model  of  work  components: 

WR  - (kJ.H  + ctsN  ♦ (k,  ♦ k3)  K2]/60 

where 

* 

N,  k^,  and  k^  are  described  as  above  for  the  team  model . 

k|  is  the  R controller  routine  workload  weighting  measured  in 
man-sec/aircraft. 

c is  the  surveillance  workload  constant  measured  in  man* sec/ 
aircraft-sin. 

t is  the  average  sector  flight  time,  measured  in  min. 


kj  i*  the  sum  of  workload  weightings  from  three  equations  representing 
three  categories  of  crossing  conflict:  level/level,  level /transitional, 

and  transit ional/ transitional. 
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The  importance  of  the  workload  component  structure  of  the  team  and 
R contr'  _ler  models  is  the  capability  to  distinguish  the  control  wrrk 
requirements  of  different  sectors  in  a manner  that  is  sensitive  to  each 
sector's  operational  characteristics.  Sector  routine  workload  time 
(k^N  or  k^N)  increases  in  direct  proportion  to  the  traffic  flow  rate 
but  varies  from  one  sector  to  another  depending  on  the  pattern  of  traffic 
flow  through  each  sector  as  well  as  each  sector's  procedural  rules.  For 
example,  the  routine  workload  weighting  (k^  or  k*)  for  an  arrival  sector 
(where  vectoring  instructions  are  frequent)  would  differ  from  that  of  a 
high  enroute  sector  (where  vectoring  is  not  as  frequent). 

The  surveillance  workload  time  (ct  N)  increases  in  direct  proportion 

to  sector  flight  time;  therefore,  surveillance  work  is  sensitive  to  the 

geographic  size  of  a sector  as  well  as  the  traffic  flow  rate.  The  flight 

time  parameter  (t  ) distinguishes  the  surveillance  work  requirements  of 
s 

different  sectors  because  the  same  sur'"'* 1 lance  workload  constant  (c) 
applies  to  each  sector.  The  product,  ct^,  is  considered  to  be  the  sur- 
veillance workload  weighting  measured  in  man-sec/alrcraft . 

Relative  to  processing  of  potential  crossing  and  overtaking  con- 

2 2 

flicts,  workload  times  (k^N  and  k^N  ) increase  with  the  square  of  the 
traffic  flow  rate.  The  conflict  workload  weightings  (k?  and  k^)  cal- 
culated for  one  sector  would  differ  from  those  of  another,  depending 
on  the  complexity  of  each  sector's  route  structure  and  its  procedural 
rules.  In  particular,  the  derivations  of  the  conflict  workload  weightings 
can  model  a variety  of  aircraft  crossing  and  merging  situations  (e.g., 
level/level,  level/climb,  climb/climb,  level/descent). 

Workload  is  used  to  define  the  craffic  capacity  of  a sector  under 
the  assumption  that  the  number  of  aircraft  that  can  be  handled  through 
a sector  during  any  given  time  is  limited  by  controller  or  control  team 
capability  to  perform  required  communication,  data  maintenance,  and 
decision  making.  Observations  of  sector  operations  indicate  that  there 
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is  a maximum  total  time  that  a controller  or  control  team  can  spend  per- 
forming contrv  1 tasks.  During  the  Los  Angeles  Center  case  study,  cali- 
bration of  the  two-man  sector  team  workload  model  using  interviewed 
controllers'  estimates  of  sector  capacities  found  that  66  man-rain/hr  of 
team  routine  and  conflict  work  corresponded  to  reported  capacities 
measured  in  aircraft/hr.  Using  the  calibrated  Los  Angeles  Center  sector 
capacities,  the  R controller  workload  threshold  was  determined  to  be  48 
man-min/hr.  These  workload  thresholds--66  man-min/hr  for  the  two-man 
sector  team  and  48  man-min/hr  for  the  R controller- -were  used  subsequently 
to  estimate  sector  capacities  for  the  Atlanta  Center. 

We  note  that  the  calibrated  team  model  is  "descriptive"  in  nature 
and,  the  same  as  regression  analysis,  empirically  relates  observed  data 
(controller  activities)  to  an  outcome  (sector  capacity).  The  R controller 
model  is  an  attempt  to  develop  a "causative"  model  of  controller  behavior 
by  accounting  for  all  the  work  associated  with  this  position.  It  was, 
therefore,  necessary  to  include  inferentially  derived  (from  controller 
interviews)  surveillance  workload,  which  is  not  based  on  observed  data. 

A similar  attempt  to  derive  a causative  model  for  the  D controller  was 
not  successful  because  we  could  not  determine  with  certainty  his  sur- 
veillance requirements  which  were  complicated  by  D controller  require- 
ments to  respond  to  R controller,  PVD,  computer  readout  device  (CRD), 
and  FDP  activities). 

In  the  following  paragraphs,  the  derivation  of  the  team  aid  R- 
controller  workload  weightings  and  capacity  calibration  are  reviewed. 

4.2.1  Routine  Work 

The  routine  workload  time  (kjN  or  k^N)  represents  the 
ordinarily  occurring  control  events  required  to  clear  aircraft  through 
the  sector;  it  is  generated  in  some  form  by  every  flight.  Field  data 
collected  at  the  Los  Angeles  Center  for  each  sector  were  used  to  identify 
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the  team  routine  control  events,  specify  the  set  of  tasks  required  to 
effect  each  event,  determine  task  performance  times  (minimum  times), 
and  measure  the  frequency  of  occurrence  of  each  event  by  sector. 

Each  routine  event  was  inch  Jed  in  one  of  the  following 
functional  categories: 

• Control  jurisdiction  transfer 

• Traffic  structuring 

• Pilot  request 

• Pointout 

• General  intersector  coordination 

• General  system  operation. 

The  control  jurisdiction  transfer  is  the  collection  of  control 
events  required  to  hand  off  an  aircraft  from  one  sector  to  another. 

Traffic  structuring  refers  to  the  procedural -based,  decision-making 
process  of  guiding  aircraft  through  a sector.  Pilot  requests  result 
in  real-time  flight  modifications,  adding  work.  Poir.touts  arc  actions 
required  by  a sector  team  to  retain  control  of  aii craft  briefly  in  or 
near  another's  airspace.  General  intersector  coordination  includes  those 
informational  transfers  that  are  performed  to  keep  cognizant  of  multi- 
sector traffic  movement,  but  are  not  part  of  handoff,  traffic  structuring, 
pilot  request,  or  pointout  activities.  General  system  operation  refers 
to  the  remaining  activities  not  included  in  the  above  categories,  activities 
such  as  equipment  operation  and  flight  data  maintenance. 

These  routine  events  provided  an  adequate  basis  for  a first- 
order  calibration  of  sector  team  workload  limitations  on  traffic  capacity, 
but  they  lacked  sufficient  operational  detail  to  support  subsequent 
productivity  evaluations  of  potential  design  modifications  to  ATC  system 
equipment.  For  this  purpose,  routine  events  were  described  on  the  basis 
of  identifiable  controller  tasks.  Each  routine  event  was  defined  to 
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consist  of  a single  task  or  a sequence  of  tasks  that  must  be  performed 
to  complete  the  event.  The  tasks  that  were  identified  are: 

• A/G  radio  communication 

• FDP/RDP  operation 

• Flight  strip  processing 

• Interphone  communication 

• Direct  (face-to-face)  voice  communication. 

A routine  control  event  represents  the  operational  consequence 
of  a specific  task  or  tasks  set.  For  example,  one  control  event  routinely 
required  for  control  jurisdiction  transfer  is  handoff  acceptance.  This 
event  requires  the  controller  to  perform  manual  FDP/RDP  operations  and 
flight-strip  processing  tasks.  On  the  other  hand,  an  altitude  instruc- 
tion event  issued  by  the  controller  as  part  of  the  traffic  structuring 
function  might  entail  only  the  A/G  communication  task. 


Results  of  field  experiments  enabled  the  specification  of 

individual  task  times  and  the  frequency  of  occurrence  of  each  event  by 

sector  for  the  observed  team  operation.  These  data  were  used  to  cal- 
* 

culate  the  routine  workload  weighting,  k^,  for  the  team  model: 
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The  summation  process  requires  that  the  minimum  performance  times  of 
all  the  "control  tasks"  (interphone  communications,  FDP/RDP  operations, 
fllcht  strip  processing,  etc..  Indexed  by  j)  be  first  sussaed  under 
each  "control  event  type"  (Indexed  by  i);  then  the  total  event  minimum 
performance  time  is  multiplied  by  the  frequency  of  the  event. 
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where 


is  the  frequency  of  occurrence  of  type  i routine  events 
measured  in  events/aircraft. 


t 


ij 


is  the  minimum  performance  time  required  for  all  type  j 
team  tasks  included  in  the  routine  event  i,  measured  in 
man-sec/event. 


A subset  of  the  team  routine  tasks  was  allocated  to  the  R 
controller  to  model  his  routine  work  during  intense  traffic  activities. 
The  allocations  were  based  on  observations  of  R-controller  actions  and 
interviews  with  controllers,  and  obtained  the  routine  workload  weighting, 
k',  for  the  R controller  model  by  sector: 


t 


ij 


i J 


where 

r^,  i,  and  j are  as  defined  for  the  team  model. 

t*  is  the  minimum  performance  time  required  for  all  type  j 
R-controller  tasks  included  in  routine  event  i,  measured 
in  man-sec/event. 

4.2.2  Surveillance  Work 

Surveillance  workload  time  (ct  N)  is  the  time  spent  scanning 

8 

the  PVD.  Past  data  collection  efforts  were  not  able  to  measure  in  the 
field  the  number  of  times  a controller  looks  at  the  PVD  or  the  duration 
of  each  look.  Instead,  assumptions  are  formulated  regarding  surveil- 
lance frequency  and  time  duration;  the  following  assumptions  are  de- 
veloped from  interviews  with  controllers  and  reflect  their  perceptions. 


For  potential  crossing  and  overtaking  conflict  processing, 

2 2 

the  workload  times  (k^N  and  k^N  ) represent  the  time  spent  (including 
communications  and  decision  making)  to  maintain  separation  assurance. 
Aircraft  conflict  situations  arise  when  there  is  a prospective  violation 
of  the  minimum  separation  allowable  between  aircraft.  Because  prevention 
of  such  situations  requires  corrective  action  In  advance,  conflict 
avoidance  by  the  controller  necessitates  a rather  we 11 -developed  capa- 
bility to  perceive  potential  conflict--to  mentally  project  flight  trajec- 
tories. The  R controller  activities  are  detection,  assessawnt,  and 
resolution  of  potential  conflicts. 

To  estimate  the  conflict  processing  workload  weightings 
(k^  and  k^),  v»  use  the  duration  of  each  conflict  processing  event  and 
its  frequency  of  occurrence: 

k.  * t e 
2 c c 
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where 


tc  and  t0  are  the  minimum  performance  times  required  for 
crossing  and  overtaking  conflict  processing,  measured 
in  man-sec/conflict. 


ec  and  e0  are  conflict  event  frequency  factors  that  measure 
the  rates  of  occurrence  of  crossing  and  overtaking  con- 
flict events,  measured  in  (conflicts/hr)/(aircraft/hr)2. 

The  conflict  processing  times  (t  , t ) are  determined  by 

c o 

estimating  and  summing  the  minimum  times  typically  needed  for  the  detec- 
tion assessment,  and  resolution,  tasks.  These  task  times  are  based  on 
field  observation  of  control  activity  and  subsequent  interviews  of 
controllers  using  videotape  playback  of  the  observed  situation  to 
review  controller  actions. 

The  hourly  conflict-frequency  factors  (e  , e ) determine  the 
2 2 co 

number  of  conflicts/hr  (e  N and  e N ) for  any  hourly  traffic  flow  rate, 

c o 

N,  and  represent  the  total  number  of  conflicts  that  may  be  occurring  at 
one  or  more  conflict  points  in  the  sector.  These  factors  are  calibrated 
for  each  sector  through  the  use  of  mathematical  models  that  determine 
the  expected  frequency  of  occurrence  of  each  conflict  type  at  each 
selected  location  or  along  each  selected  route.  The  models  define 
conflict  frequencies  as  functions  of  aircraft  speeds,  route  intersection 
angle,  route  lengths,  and  minimum  separation  requirements  as  perceived 
by  controllers.  These  relationships  are  formulated  as  the  summation  of 
the  probability  of  pairwise  conflicts  between  aircraft.  The  models 
and  their  use  for  calculating  frequency  factors  are  described  in 
Appendix  D. 

4.2.4  Workload  and  Capacity  Calibration 

The  observed  work  activity  data  (i.e.,  exclusive  of  the  in- 
ferentially  derived  surveillance  workload)  and  reported  sector  capacity 
data  were  used  to  calibrate  a workload  threshold  for  the  two-man  team 
model  for  four  sectors  of  the  Los  Angeles  Center.  A workload  threshold 
for  the  R-controller  model  was  then  identified  using  the  workload  and 
traffic  capacity  relationships  of  the  team  model. 
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4 . 2 . 4 . 1 ii-ujn  Model  Cul tt>rm  1 on 

To  establish  empirically  the  relationship  between  sector 
team  workload  and  traffic  capacity,  extensive  interviews  with  controllers 
addressed  the  maximum  sustainable  traffic  flow  rates  in  each  sector. 

The  controller  est imates  (which  take  into  consideration  historical  peak 
activity  levels)  of  the  four  sector  traffic  capacities  were: 


• 40-45  aircraft/hr  for  sectors  19/20 

• 45-50  aircraft/hr  for  sector  18 

• 45-50  aircraft/hr  for  sector  7 

• 50-55  aircraft/hr  for  sector  36. 

The  sector  capacity  estimates  were  compared  against 
sector  workload  calculated  using  the  team  model  as  shown  in  Figure  2. 

The  midpoint  of  each  capacity  range  (indicated  by  parentheses)  cor- 
responds closely  to  66  man-min/hr  of  calculated  team  workload;  this 
value — 66  man-mm/hr--was  defined  to  be  the  two -man  team  workload  threshold. 
The  hourly  traffic  rates  corresponding  directly  to  this  threshold 
(indicated  by  the  dotted  lines)  were  used  as  point  estimates  of  each 
sector's  capacity.  These  model-estimated  capacities  are  43,  48,  46,  and 
52  aircraft/hour  for  sectors  19/20,  18,  7,  and  36,  respectively;  all 
fall  within  the  capacity  range  estimated  by  controllers. 

4. 2.4. 2 R-Controller  Workload  Calibration 

To  ascertain  the  R-controller  total  workload  correspond- 
ing to  the  sector  traffic  capacities,  the  R-controller  model  was  used 
to  calculate  workload  at  the  capacity  flow  rates  as  summarized  in 
Table  3. 

Although  the  team  workload  corresponding  to  the  sector 
traffic  capacities  is  66  man-min/hr,  the  R-controller  total  workload 
varies  from  45  to  51  man-min/hr.  These  data  imply  that  R controllers 
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FIGURE  2 SECTOR  TEAM  WORKLOAD  CALIBRATION 
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of  different  sectors  are  not  working  at  equal  levels  of  effort  under 
traffic  capacity  conditions.  Assuaing  each  R controller  is  responsible 
for  the  sane  types  of  duties,  regardless  of  sector,  and  that  these 
duties  are  as  defined  by  the  workload  allocation  formulations,  one  finds 
the  Sector  36  R controller  is  devoting  more  raan-minutes  of  effort  to 
his  capacity  traffic  than  are  the  others,  Los  Angeles  Center  personnel 
indicated  that  Sector  36  is  the  "hardest"  sector  to  work. 


TABLE  3 


RADAR-CONTROLLER  WORKLOAD  CALIBRATION 


Sector 

Estimated 

Capacity* 

(aircraft/ 

hr) 

Workload  (man-min/hr) 

Workload 

Intensity 

Factorf 

Routine 

Conflict 

Total 

Low  arrival  (19/20) 

43 

8 

34 

6 

48 

0.80 

Low  departure  (18) 

48 

9 

6 

45 

0.75 

Low  enroute  (7) 

46 

1) 

n 

48 

0.80 

Low  transition  (36) 

52 

13 

mm 

51 

0.85 

* 

Estimated  capacity  corresponds  to  a workload  threshold  of  66  men-min/hr. 

^Workload  intensity  factor  is  based  on  a maximum  R-controller  availability 
of  60  sun-min/hr. 

The  average  R-controller  workload  at  capacity  for  the 
four  sectors  is  48  man-ain/hr.  The  significance  of  this  value  to  the 
R controller  can  be  examined  using  the  concept  of  workload  intensity. 

The  total  time  available  to  the  R controller  to  perform  work  is  60  man- 
ain/hr,  and  the  proportion  of  this  hour  actually  consumed  in  measurable 
work  is  called  the  workload  intensity  factor;  these  are  listed  in 
Table  3.  If  the  arrival  pattern  of  control  events  for  the  R controller 
over  a long  period  of  time  (e.g.,  one  hour)  is  suitably  random,  an 
analogy  to  the  traffic  intensity  factor  of  standard  single-server  queueing 
modeling  can  be  atfde.  It  has  been  shown  that,  as  the  intensity  factor 
approaches  a magnitude  of  the  order  of  0.80,  the  queueing  system  nears 
instability.  This  implies  that,  if  over  a long  time  period  the  R con- 
troller is  working  under  too  high  a workload  intensity  factor,  he  is 
in  danger  of  suddenly  receiving  a surge  of  traffic  over  a short  time 
period  (e.g.,  5-10  min)  that  he  cannot  handle.  In  controller  terminology, 
such  a surge  would  cause  the  R controller  to  "go  under." 
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Ac  capacity,  Che  R controller*  of  Sectors  19/20,  7,  and 
36  are  working  under  workload  Intent lty  factors  equal  to  or  greater 
than  0.80  (48  man-min/hr) ; in  Sector  18  the  factor  is  0.75.  Although 
the  Sector  18  R controller  may  be  able  to  accept  additional  work  over 
the  long  term,  the  additional  work  could  not  be  accepted  by  the  sector 
team  as  a whole.  The  sector  is  already  operating  at  its  traffic  capacity 
rate.  Therefore,  the  sector  team  workload  threshold  of  66  man-mln  is 
constraining  the  capacity  of  Sector  18. 

At  capacity,  Sectors  19/20  and  7 are  experiencing  R- 
controller  workloads  of  48  swn-oin  (the  maximum  team  workload  allowable), 
but  the  Sector  36  controller  experiences  a 51  man -min  (0.85  intensity) 
workload.  Despite  the  anomaly  of  Sector  36,  it  appears  that  48  man-mln 
Is  a reasonable  estimate  of  R-controller  workload  threshold.  Therefore, 
this  threshold  value  was  used  as  a check  to  ensure  that  overall  sector 
teamwork  does  not  overload  the  R position. 

4.3  DATA  COLLECTION  AND  REDUCTION 

As  a result  of  various  ATC-related  data  collection  exercises,4"'7 
SRI  has  developed  a data  col lection/ reduct ion  procedure  for  NAS  Stage  A 
equipped  enroute  facilities  that  is  based  on  the  following  data  sources: 

• Video  tape  recordings  of  PVD*. 

• Audio  (including  video  tape  sound  track)  recordings  of 
A/G  and  interphone  communications. 

• Manual  recordings  of  observed  controller  physical  actions. 

• NAS  Stage  A data  analysis  and  reduction  tool  computer  print' 
out  records  of  R and  D position  FDP/RDP  operations. 

• Flight  strips,  used  and  marked-on  by  controller. 

These  data  are  collected  during  a one-hour  observation  of  a selected 
sector's  control  activities.  Each  observation  session  is  followed  by 
a one-hour  structured  Interview  of  the  sector's  controllers.  The 
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Interviewer  uses  video  tape  playback  during  examination  and  discussion 
ill  i he  o|m* t'nl  ImikiI  mi  i nl  e|/ lent  |irm'<*ilureii,  mid  leelnili|U('H  «*irployt,d  by 
the  controllers. 

As  part  of  the  date-reduction  process,  data  measurements  are 
assembled  Into  a format  that  facilitates  cross-reference  of  the 
observed  activities  and  permits  a reconstruction,  in  part,  of  the 
routine  control  events.  The  information  on  operational  procedures 
obtained  during  the  controller  interviews,  along  with  the  data  observa- 
tions, is  essential  to  identify  the  control  requirements  that  are  in  the 
logical  reconstruction  of  routine  events. 

A. 3.1  Team  Routine  Work  Measurement 

Ue  used  this  procedure  to  collect  data  from  four  sectors  at 
the  Los  Angeles  Center7  during  the  5-day  period  24-28  June  1974.  The 
center  was  then  using  the  NAS  Stage  A3d.2  system,  including  PDF  and 
RDP  capabilities,  8ecau,<*  the  data  collection  sessions  at  the  Los 
Angeles  Center  were  conducted  dur.'ng  moderate- to-heavy  traffic  activity, 
we  assume  that  these  routine  event*  are  representative  of  control 
requirements  during  capacity  condltims  (during  which  nonessential 
activities  are  minimized). 

Also,  as  part  of  the  Los  Angeles  Center  effort,  we  made 
stopwatch  measurements  of  observed  controller  manual  activities  (PDF/ 

RDP  operations,  flight-strip  processing)  and  recorded  and  observed 
oral  communications  (A/C  radio  and  interphone  communications  and  direct- 
voice  commjnicatlon).  For  each  identified  task,  we  selected  a "reasonable” 
minimum  task  performance  time  from  the  data  measurements  to  represent 
task  work  requirements  during  capacity  conditions.  In  determining 
minimum  performance  times,  we  considered  only  those  observed  or  recorded 
activities  that  we  judged  to  be  performed  completely  (satisfied  infor- 
mation transacr  .on  or  message -content  requirements)  and  with  efficiency 
(without  delay,  interruption,  or  extraneous  information). 
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He  conducted  a similar  data  collection  effort  for  seven 
sectors  at  the  Atlanta  Center  during  the  5 -day  period  15-19  December 
1975,  The  center  was  using  the  NAS  Stage  A3d.2  System,  including 
PDF  and  RDP  capabilities.  Two  airline  strikes  were  in  effect  during 
data  collection,  and  traffic  activity  was  Moderate.  Despite  the  absence 
of  heavy  traffic  loadings,  the  data  collected  and  reconstructed  sub- 
stantiated the  basic  routine  control  event  structure  resulting  from  the 
Los  Angeles  Center  effort  and  indicated  the  need  for  soae  minor  modifica- 
tions. A restricted  effort  to  spot-check  the  task  performance  times 
also  supported  the  Los  Angeles  Center  data. 

In  the  following  paragraphs,  we  review  the  data  collection 
results  and  describe  the  routine  control  events  for  the  Atlanta  Center 
data  collection  effort. 

4*3. 1.1  Team  Routine-Event  Frequency  Measurements 

The  data  sources  that  were  reduced  in  detail  for  Atlanta 
Center  were  the  audio  recordings  and  the  DART  computer  printouts. 

Flight  strips  were  also  collected,  but  not  Individually  studied  in  de- 
tail. Although  observations  of  controller  actions  were  made,  manual 
task  activities  and  performance  times  were  not  recorded  systematically. 
Because  of  our  previous  Los  Angeles  data  collection  effort,  we  could 
ascertain  routine  events  using  the  audio  tapes  and  DART  printouts. 

Flight  strips  and  video  tape  recordings,  which  included  A/G  coessunica- 
tlons  on  the  sound  track,  were  used  to  develop  data  for  the  conflict 
sideling  procedures;  the  video  tapes  were  also  used  to  structure  mid 
guide  our  controller  interviews.  More  details  are  contained  in  Appen- 
dix E. 

We  conducted  a one-hour  data  collection  session  for  each 
of  the  seven  selected  sectors.  During  each  hour,  the  R-position  A/G 
and  the  D-position  interphone  oral  comaminlcations  were  simultaneously 
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recorded  by  separate  audio  tape  recorders.  The  A/G  and  Interphone 
recording  tapes  were  manually  transcribed  by  writing  the  ms  saga  end 
the  aircraft  identity.  Experienced  data  analysts,  by  a process  of 
listening  and  replaying  the  audio  tape,  prepared  handwritten  transcrip- 
tions o£  the  recot ded  voice  messages.  The  transcriptions  included  the 
message  content,  aircraft  identify  end  speaker  (i.e,  pilot  or  controller). 
Then,  by  Mans  of  carefully  scanning  and  searching  the  hard  copy  transcrip- 
tions, the  analysts  categorised  and  grouped  the  communications  according 
to  Mssage  content  and  tabulated  the  number  of  each  type  of  message 
transaction  (i.e.,  altitude,  heading,  and  speed  instruction). 

This  process  resulted  in  the  tabulation  of  A/G  communica- 
tions is  shown  in  Tak’.e  4.  a similar  tabulation  of  interphone  communi- 
cations is  shown  in  Table  5;  however,  this  tabulation  required  some 
cross-referencing  with  A/G  data  to  identify  the  event  if  a question 
existed.  (For  example,  reference  to  the  A/G  transcriptions  for  a par- 
ticular aircraft  would  determine  whether  an  interphone  communication  on 
altitude  clearance  was  a traffic-structuring  or  a pilot-request  event.) 

We  note  that  to  collect  on-site  the  appropriate  A/G  and  interphone 
communications  data,  it  is  necessary  to  use  simultaneously  two  different 
audio  recording  units,  with  each  plugged  into  the  Center's  own  recording 
systew. 

DART  computer  printout  records  of  1 and  0 position  FttP/ 

RDP  data  entry  and  display-related  operations  were  obtained  from  Atlanta 
Center  data  systems  personnel  in  accordance  with  the  print  option  re- 
quested by  the  survey  tean.  This  option  should  include  a record  of  the 
R,  D,  and  A position  data  entries  and  the  CRD  data  displayed  to  them; 
aircraft  tracking  data  la  not  required.  This  DART  option  essentially  is 
a transcription  of  FDP/RDP  operations  performed  by  each  controller  during 
the  data  observation  session  and  contains  codad  data  describing  the 
message  content  of  each  data  entry  or  display,  as  we' l as  the  identity  of 
the  aircraft  involved. 

4V 


i 


a 


^T]pj!niprrp^’"5t« 


V 4*  *rl  -P  3 

dUllf 

M 

H 


MW*  9 W W 

•w  *-  5 b a 

tJ  W 9 S«4  t) 


K 5 K I « t 

0 W W O • 
u u <J  m -H  > 

• Mi<  w in 

1 w > m y*  m 
u m -a  u u ts 

O "*  M W 8 

^ e f - o 8 

H 6 d H fc  to 

4 4i  a p w 3 

llPId 


Each  DART  record  collected  at  the  Atlanta  Center  cor- 


responded  to  about  a 1. 25-hour  period  overlapping  the  1-hour  data  col- 
lection. The  DART  transcriptions  were  manually  scanned  and  searched, 
and  a record  was  prepared  of  the  FDP/RDP  operations  (e.g.,  handoff 
acceptance,  altitude  amendment,  and  data  block/ leader  line  offset) 
performed  for  each  aircraft  identified.  An  operation  could  be  identified 
from  the  DART  printout  by  the  quick-t  .tlon  key  and  data  format.  This 
process  resulted  in  the  tabulation  of  the  FDP/RDP  operations  shown  by 
sector  in  Table  6.  Again,  cross-referencing  with  the  A/G  or  interphone 
data  was  sometimes  required  to  identify  events.  (For  example,  reference 
to  A/G  transcriptions  for  a particular  aircraft  would  determine  whether 
a flight  data  altitude  amendment  was  a traffic  structuring  or  a pilot 
request  event.) 

These  three  tables  were  then  mutually  cross-referenced  to 
construct  the  routine  control  event  tabulation  shown  by  sector  in  Table  7. 
This  construction  required  us  to  make  logical  interpretations  of  event 
characteristics  based  on  judgment  and  the  average  hourly  flow  rate;  the 
latter  is  the  average  of  a sector's  aircraft  exits  and  entries,  as  cal- 
culated in  Table  4.  For  example,  the  number  of  handoff  acceptance, 
initial  pilot  call-in,  and  frequency  change  instruction  events  is  assumed 
to  be  equal  to  the  hourly  traffic  flow  rate;  the  number  of  automatic 
handoff  initiations  is  equal  to  the  algebraic  difference  between  the 
numbers  of  handoff  acceptance  and  manual  handoff  initiation  events. 

The  entries  in  Table  7 were  divided  by  the  average  hourly  flow  rate 
to  obtain  the  team  routine  event  frequencies  shown  in  Table  8. 

Because  of  an  audio  tape  malfunction,  no  interphone  data 
were  obtained  for  Sector  37.  Xn  Table  8,  we  substituted  the  interphone 
frequencies  of  Sector  42  for  those  of  Sector  37  because  both  are  transi- 
tion sectors.  Because  manual  task  activity  observations  were  not  re- 
corded, no  data  were  obtained  for  flight  strip  sequencing/ removal  and 
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TABLE  7 

HUMBER  OF  ROUTINE  CONTROL  EVENTS,  CURRENT  NAS  STAGE  A,  ATLANTA  CENTER 
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TABLE  8 

ROUTINE  EVENT  FREQUENCY  ESTIMATES 
ATLANTA  CENTER,  TWO-MAN  SECTOR  OPERATIONS 
SYSTEM  1A— NAS  STAGE  A BASE 
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equipment  adjustment.  Also,  the  number  of  events  observed  at  some 
sectors  for  data  block/leader  line  offset  and  data  block  forcing/ removal 
appeared  too  large  to  be  representative  of  capacity  or  heavy  traffic 
conditions.  This  conclusion  is  based  on  a small  sample  of  observations 
at  Atlanta  in  that  the  frequency  of  such  event  d4>  4nishes  during  short 
traffic  surges.  For  each  of  these  four  events  we  assigned  eve.it  fre- 
quencies (Table  8)  that  were  adjusted  in  accordance  with  the  Los  Angeles 
Center  data. 

The  audio  tapes  of  A/G  and  interphone  communications  and 
the  DART  transcription  obtained  during  the  field  experiment  will  provide 
sufficient  data  to  estimate  the  frequencies  of  the  great  majority  of 
the  routine  control  events.  However,  for  completeness,  some  additional 
data  should  be  collected.  For  example,  the  number  of  hand-written 
flight  strips  (i.e.,  those  not  printed  by  the  FDP  printer)  obtains  the 
number  of  new  flight  strip  events  performed  for  pop-ups.  These  data 
could  also  be  obtained  by  on-site  observations  of  control  team  activities, 
as  could  the  number  of  flight-strip  sequencing/ removal  and  equipment 
adjustment  events. 


4.3. 1.2  Team  Routine- Event  Minimum  Performance  Time  Measurements 


Stopwatch  measurements  of  observed  and  recorded  minimum 
task  performance  times  are  summarized  in  Table  9.  The  set  of  routine 
control  events  shown  are  actually  identified  or  finalized  upon  comple- 
tion of  the  off-site  reduction  effort,  which  Includes  determining  event 
frequencies.  Note  that  this  set  is  based  on  field  experiments  conducted 
at  the  Atlanta  and  Los  Angeles  Centers  and  essentially  is  a description 
of  those  events  performed  during  our  data  collection  sessions.  There- 
fore, it  is  possible  that  "new"  events  might  be  observed  if  the  experi- 
ments were  to  be  repeated  at  some  other  site,  necessitating  estimation 


56 


tabu:  9 


f**k  Pfff'nMK. 


if*  bi*f<  cm  iiti  cot  IcctH  it  tH*  Ul  Ai|*Ul  Cntif, 


t*Hic  •t*,4  4ii<i<  « * 


*h,  *r«*i.r«4!  direct  vole#  cl 


KlCit^M  ti*tf  <oritl«A. 


1 


of  their  alnlaua  performance  timet.  For  this  reason,  and  for  the  take 
of  confirming  the  previously  estimated  event  performance  times,  we 
suggest  that  subsequent  field  experiments  should  include  at  least  a 
program  to  check  the  minimum  times  required  by  the  various  tasks. 

On-site  task  performance  time  measurements  need  not  be 
an  elaborate  program  because  many  of  the  measurements  can  be  made  after 
completion  of  the  field  experiment  and  after  all  events  have  been  iden- 
tified. All  A/G  and  interphone  voice  communication  message  times  can 
be  obtained  from  the  audio  or  video  tape  records  using  a stopwatch. 

The  remaining  tasks,  those  that  can  be  observed  only  at  the  facility, 
have  been  found  to  fall  into  a limited  number  of  performance-time  groups. 
FDP/RDP  operations  may  take  1,  2,  3 or  10  seconds  respectively  when  a 
single-key  operation  is  required  (i.e.,  to  clear  the  CRD),  when  function- 
key  and  aircraft  identification  operations  are  required  (i.e.,  accept 
handoff),  when  function-key,  aircraft  identification,  and  limited-data 
entry  operations  are  required  (e.g.,  flight  data  altitude  amendment), 
or  when  function-key,  ACID  and  extended-data  entry  operations  are  re- 
quired (e.g.,  flight  data  route  ammendment). 

Flight-strip  processing  was  found  to  require  i second 
to  confirm  data  printed  on  the  strip  (e.g.,  manually  "check-off"  an 
altitude  entry),  2 seconds  to  update  numeric  data  on  an  active  strip 
(e.g.,  write  a new  altitude  clearance)  or  sequence  or  remove  a strip, 

3 seconds  to  update  flight  data  estimates  on  a proposal  strip  (e.g., 
copy  CRD-displayed  altitude  revision),  or  10  seconds  to  prepare  a new 
strip  or  revise  a routing. 

Direct  voice  communications,  which  are  face-to-face  con- 
versations between  an  R and  a D controller,  were  found  to  take  at  least 
3 seconds,  but  may  take  A seconds  if  discussions  of  routings  are  in- 
volved. (These  task  times  are  doubled  in  Table  9 to  account  for  the 
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tine  both  controllers  spend  in  a direct-voice  cosaaunication  with  each 
other.) 

The  event  performance  times  are  obtained  in  Table  9 by 
summing  the  contributing  task  minimum  performance  times.  Although  this 
process  is  part  of  the  off-site  data  reduction  and  not  directly  included 
in  on-site  field  experimentation,  it  is  advisable  to  develop  a knowledge 
or  "feeling''  for  the  task  composition  of  each  event  during  the  data 
observations.  This  knowledge  will  assist  the  analyst  to  comprehend  and 
estimate  the  impact  of  postulated  automations  and  controller  task  re- 
quirements. 

A. 3. 1.3  Team  Routine  Control  Event  Susmsary 

The  following  discussion  provides  an  overview  of  the 
routine  control  events  we  associated  with  en route  sector  operations. 

These  events,  which  are  listed  in  Table  10  and  11  were  developed  from 
our  data  observations  and  controller  interviews  to  define  control  ac- 
tivities as  logical  representations  of  operational  requirements. 

Table  1C  Includes  a brief  susnary  of  the  controller  activities  associated 
with  each  event  and  parallels  this  discussion. 

Control  Jurisdiction  Trans fer--A  handoff  between  two 
sectors  transfers  authority  over  an  aircraft  and  full  access  to  the 
aircraft's  computer  data  file  from  one  terns  to  the  other  (direct  contrv* 
is  effected  when  the  aircraft  crew  switches  onto  the  receiving  sector's 
A/G  radio  frequency).  A silent  handoff  (i.e,,  a procedure  not  routinely 
requiring  Intersector  Interphone  coiunlcation)  is  initiated  either 
automatically  by  the  NAS  Stage  A computerised  operations  or  manually 
by  a sector  team  using  FDF/RDP  keyboard  or  trackball  operations,  or 
both.  Either  handoff  initiation  mode  caused  a blinking  "H"  and  the 
receiving  sector's  identity  numbers  (e.g.,  "H-36")  from  the  aircraft's 
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TABLE  10  (CONCLUDED) 


TABLE  11 


R-CONTROLLER  ROUTINE  EVENT  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
ATLANTA  CENTER,  TWO-MAN  SECTOR  OPERATION 
SYSTEM  IA— NAS  STAGE  A BASE 
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data  block  to  appear  on  the  PVDs  of  both  the  initiating  and  receiving 
sectors.  Kandoff  acceptance  is  performed  manually  using  FDP/RDP  opera- 
tions and  causes  the  flashing  "H"  to  be  replaced  by  the  letter  "0",  which 
is  retained  for  about  one  minute  on  both  PVDs.  The  receiving  sector 
team  manually  marks  the  letter  "R"  (for  radar  contact)  on  its  flight 
strip  for  that  aircraft,  and  the  initiating  sector  team  marks  a circle 
around  its  "R". 


Handoffs  between  NAS  Stage  A sectors  and  non-NAS  Stage  A 
or  ron-ARTS  III  facilities  cannot  be  perforated  silently  and  require 
interphone  communications  to  transfer  control  jurisdiction.  The  NAS 
Stage  A sector  also  performs  FDP/RDP  keyboard  and  trackball  operation 
to  initiate  or  drop  computerized  radar  tracking.  This  activity  is 
normally  accompanied  by  an -additional  FI"  operation  to  input  flight  data 
updating  information  (e.g.,  departure  message,  altitude  clearance). 

Intersector  coordinations  sometimes  accompany  silent 
handoffs  when  standard  control  procedures  are  not  strictly  followed 
(e.g.,  as  a result  cf  conflict-avoidance  instructions).  Interscctor 
coordinations  generate  intrascctor  consultation  between  R and  & con- 
trollers to  confirm  information  transfers.  In  cases  of  sr.  unexpected 
aircraft  pop-up,  a paper  flight  strip  for  the  aircraft  is  manually  pre- 
pared by  the  D controller. 


Traffic  Structurir.g--These  events  include  the  procedural- 
based  activities  routinely  required  to  process  an  aircraft  through  A 
sector.  The  traffic  structuring  basic  events  are  all  Initiated  by  A/C 
communications  and  generally  Include  some  manual  data  updating  or  re- 
cording task.  Each  A/G  coesaunt cat ice;  task  entail.’;  negotiation  or  con- 
firmation between  pilot  and  controller.  The  first  traffic  structuring 
event  for  an  aircraft  is  the  pi.ot’s  initial  flight  identity  and  altitude 
report  call-in,  which  is  manually  "checked"  on  the  flight  strip.  If  the 
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aircraft  is  not  equipped  with  automatic  altitude  reporting  (Mode  C) 
equipment,  the  reported  altitude  is  manually  entered  into  the  FDP  data 
file  by  keyboard  operation  and  marked  on  the  flight  strip.  Altitude, 
heading,  and  speed  instructions  and  pilot  reports  are  manually  recorded 
on  flight  strips.  When  altitude  clearances  do  not  conform  to  current 
flight  plans  or  when  a reported  altitude  is  not  from  a Mode  C-equipped 
aircraft,  the  FDP  flight  plan  data  file  is  amended  cr  the  PVD  altitude 
display  is  corrected  by  manual  keyboard  insertion.  Interphone  co- 
ordinate. *,s  initiated  by  a sector  team  are  generally  requests  to  adjacent 
sector  teams  to  approve  and  confir..  cne  issuance  of  nonstandard  traffic- 
ftructuring  instructions.  Altimeter  setting  and  runway  assignment  in- 
structions are  routinely  issued  by  low-altitude  sectors  to  assist 
climbing  and  descending  aircraft.  Traffic  advisories  describing  proxi- 
mate traffic,  transponder  code  corrections,  and  miscellaneous  A/G 
coordinations  (e.'  . radio-failure  assistance)  arc  performed  as  needed. 

A controller-to-pilot  instruction  to  change  radio  frequency  to  that  of 
the  I’ext  sector  culminates  the  traffic-structuring  activity  for  an 
aircraft;  it  is  manually  recorded  on  the  aircraft's  flight  strip  at  the 
Los  Angeles  Center  by  marking  a second  circle  around  the  "R"  and  at 
the  Atlanta  Center  by  marking  a cross-line  through  th  ''check."  (The 


frequency-change  instruction  is  immediately  preceded  by  formal  hand- 
off  initiation  and  acceptance  of  control  jurisdiction  by  the  two  sector 
teams. ) 


Pilot  Request--Task  requirements  generated  by  pilot 
requests  to  revise  altitude,  route,  heading,  or  speed  clearances  are 
essentially  similar  to  those  of  traffic  structuring  except  that  they 
are  initiated  by  an  aircraft,  crew.  All  are  initiated  by  A/G  communica- 
tions and,  except  for  miscellaneous  requests  such  as  navigation  assis- 
tance or  weather  information,  entail  flight-strip  processing.  FDP/RDP- 
based  data  amendments  or  intersector  coordinations  are  performed  as 
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required.  In  some  low  sectors,  clearance  deliveries  to  approve  flight 
plan  routing  are  issued  directly  to  pilots  (rather  than  a terminal 
facility),  by  means  of  A/G  communication.  Such  clearance  deliveries 
require  FDP/RDP  operations  to  update  the  flight  progress  data  in  the 
computer  file  (e.g.,  departure  message,  altitude  clearance),  and  flight- 
strip  marking  to  record  the  issuance  of  the  clearance  delivery  (any 
additional  flight  strip  or  FDP  data  revisions  that  may  be  required 
are  assumed  to  occur  simultaneously  with  the  A/G  communication). 

Pointou£- -Pointout  actions  are  required  by  a sector  team 
to  retain  control  of  aircraft  briefly  in  or  near  another's  airspace. 

A pointout  initiation  entails  RDP  keyboard  operations  to  force  an  air- 
craft's alphanumeric  data  block  onto  an  adjacent  sector  team's  PVD  and 
flight  strip  marking.  Because  the  sector  team  receiving  the  forced 
data  block  normally  has  no  flight  strip  pertaining  to  the  aircraft  in 
question,  interphone  communications  are  needed  to  transmit  relevant 
flight  information.  The  receiving  sector  may  also  display  pertinent 
FDP  data  on  its  D-position  CRD,  although  this  normally  occurs  during 
the  intersector  coordination.  The  receiving  sector,  by  means  of  manual 
RDP,  keyboard/ trackball  operations  may  suppress  the  forced  data  block 
display  as  desired. 

General  Intersector  Coordination- -These  events  include 
those  informational  transfers  that  are  performed  by  sector  teams  to 
maintain  mutual  cognizance  of  multisector  traffic  movement  and  that  are 
not  part  of  handoff,  traffic  structuring,  pilot  request,  or  pointout. 
General  intersector  coordination  events  almost  entirely  entail  telephone 
and  direct  voice  communications.  Control  instruction  approvals  are 
issued  in  response  to  other  sector  teams'  traffic  Instruction  and  pilot- 
request  activities.  Planning,  aircraft  status,  and  control  jurisdiction 
advisories  are  used  to  clarify  general  procediral  and  individual  aircraft 
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situations.  Clearance  deliveries  are  negotiations  with  airport  towers 
to  approve  flight  routings  if  silent-departure  procedures  are  not  estab- 
lished and  include  manual  flight  strip  marking  to  indicate  issuance 
of  the  clearance.  FDP/RDP  keyboard  operations  are  necessary  for  updating 
flight-progress  files  (e.g.,  departure  message,  altitude  clearance)  if 
the  tower  is  not  FDP  equipped. 


General  System  Operation--In  this  category  are  those 
activities  not  included  in  the  above  descriptions,  such  as  equipment 
operation  and  data  maintenance.  General  system  operation  events  are 
entirely  performed  by  FDP/RDP  operation  and  flight-strip  processing. 
Flight-plan  update  messages  (e.g.,  altitude,  route,  or  beacon  code  re- 
vision; expected  position  fix  time  arrival;  airport  departure  confirma- 
tion) from  incoming  flights  displayed  on  the  D-controller's  CRD  by  the 
FDP  system  are  manually  copied  onto  the  appropriate  proposal  flight 
strips.  Using  keyboard/ trackball  operations,  the  R controller  selec- 
tively modifies  the  PVD  by  offsetting  or  reorienting  alphanumeric  data 
blocks  to  alleviate  display  clutter  and  forcing  or  removing  data  block 
displays.  (An  aircraft's  data  block  as  retained  on  the  PVD  of  a sector 
team  initiating  a handoff  for  a 5-minute  period  after  thr  handoff  has 
been  accepted  and  is  manually  forced  back  onto  the  PVD  as  required.) 
Miscellaneous  data  services  involving  FDP  system  operations  include 
requests  for  weather  and  altimeter  data  displays  and  f light-sti ip  print- 
ing, removal  if  flight  plans  from  the  data  file  and  display,  removal 
or  modification  of  PVD  tabular  listings  of  inbound,  departing,  or  holding 
aircraft,  and  CRD  listings  of  beacon  code  selections  (which  define  the 
eligibility  of  radar  target  displays)  and  altitude  limits  (which  define 
the  altitude  range  over  which  the  PVD  displays  automatic  altitude  re- 
ports for  untracKed  or  intruding  aircraft).  Arranging  and  removing  the 
flight  strips  on  the  flight  progress  board  is  performed  by  the  D con- 
troller; the  R controliei  is  responsible  for  A/C  radio  frequency  and 
RDP  (e.g.,  map  and  range  selection)  adjustments, 

be 


4. 3. 1.4  Los  Angeles  Center  Versus  Atlanta  Center  Data 


Some  differences  exist  between  the  routine  events 
observed  at  the  Atlanta  and  the  Los  Angeles  centers.  First,  automatic 
handoff  initiation  events  were  observed  at  Atlanta,  but  not  at  Los 
Angeles.  Second,  flight  data  altitude  amendments  for  traffic  structuring 
"heading  instructions"  were  observed  at  Atlanta,  but  not  at  Los  Angeles. 
Third,  the  flight  data  code  amendment  was  performed,  as  required,  in 
support  of  the  traff ic-stvucturing  transponder  code  assignment  event  at 
Atlanta;  at  Los  Angeles  it  was  assumed  to  be  an  integral  part  of  the 
transponder  code  revision  event.  Fourth,  clearance  delivery  was  issued 
directly  to  pilots  as  part  of  pilot  requests  at  Atlanta;  at  Los  Angeles, 
clearance  delivery  was  observed  to  be  issued  only  to  towers  as  parr 
of  general  intersector  coordination.  Both  types  of  clearance  deliveries 
were  observed  at  Atlanta.  Fifth,  the  flight  data  update  event  was  per- 
formed, as  required,  in  support  t'f  the  clearance  delivery  to  towers  at 
Atlanta;  at  Los  Angeles  it  was  as&umed  to  be  an  integral  part  of  the 
clearance  '.livery  event. 

These  differences  are  reflected  in  the  routine  event 
structures  shown  in  Table  9 of  this  report  and  in  Table  l of  Reference  7 
(or  2). 

We  also  note  that  some  events  observed  at  Los  Angeles 
were  not  observed  at  Atlanta.  These  include:  the  flight  data  update 

performed  on  an  as-required  basis  to  support  handoff  acceptance,  the 
traffic-structuring  runway  assignment  instruction  event,  and  the  miscel- 
laneous pilot  request  event.  To  maintain  the  generality  of  our  routine 
event  descriptions,  we  chose  to  Include  these  events  in  our  event  struc- 
ture in  Tabic  9 and  to  assign  the*  a aero  frequeniy-of-occurrence  in 
Table  8 of  this  report. 
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4.3.2  K-Controller  Routine  Work  Allocation 

Based  on  observations  and  controller  interviews  at  both  the 
Los  Angeles  and  Atlanta  Centers,  we  concluded  that  during  busy  periods 
the  R controller  concentrates  on  the  traffic  in  his  sector,  primarily 
occupying  himself  with  basic  traffic  structuring,  pilot  requests,  and 
equipment  oferation.  As  a result,  he  performs  all  A/G  communications 
as  well  as  tasks  associated  with  active  flight  strips  (including  all 
traffic  structuring  and  pilot  request  flight-strip  processing),  various 
RDP-related  actions,  and  his  half  of  direct-voice  communications. 

To  represent  the  R-controller ' s routine  work,  we  allocated 
portions  of  the  team  routine  tasks  (defined  in  Table  5),  and  obtained 
the  R-controller  tasks  as  shown  in  Table  11  for  the  Atlanta  Center. 

Those  allocations  are  not  intended  to  be  inflexible  or  firm  descriptions 
of  all  the  specified  tasks  that  must  be  performed  by  the  R controller, 
but  show  the  work  that  typically  may  be  expected  to  be  performed  by  the 
R controller  during  capacity  conditions.  We  note,  for  example,  that 
task  trade-offs  between  the  R and  D controllers  may  occur  and  are  not 
accounted  .'or  in  Table  11,  For  example,  the  R controller  may  perform 
some  manual  handoff  or  a few  voice  interphone  communications  tasks  if 
time  permits,  and  the  D controller  may  perform  some  of  the  FDP/RDP 
operation  and  flight-strip  processing  tasks  nominally  observed  to  be 
performed  by  the  R controller.  However,  in  all  circumstances,  the  R 
controller  is  expected  to  perform  all  the  A/C  coomunicatfons  tasks  and 
the  D controller  performs  mos^  of  the  interphone  communications  tasks. 

4.3.3  k-Controllcr  Surveillance  Work  Calculation 

Surveillance  workload  based  on  the  assumption  of  1.25  man-sec/ 
aircraf *.-min  for  PVD  scanning  work  is  as  shown  in  Table  12  for  the 
Atlanta  Center  sectors.  The  average  transit  times  were  assumed  to  be 


TABLE  12 


{(•CONTROLLER  SURVEILLANCE  WORKLOAD  WEICHTING,  BY  SECTOR 
ATLANTA  CENTER,  TWO-MAN  SECTOR  OPERATION 
SYSTEM  1A— NAS  STAGE  A BASE 


Sector 

Aircraft  Average 
Transit  Time 
(min) 

Surveillance 
Workload  Weighting* 
(man-sec/alrcraf t ) 

High  enroute  (36) 

20 

25 

Departure  transition  (37) 

21 

26.25 

Departure  (38) 

12 

15 

Arrival  (41) 

19 

23.75 

Arrival  transition  (42) 

18 

22.5 

Low  arrival  (46) 

21 

26.25 

Low  enroute  (52) 

14 

i 

i 

l - 

17.5 

Based  on  I. 25  man-sec/alrcraft-min. 


the  average  time  aircraft  were  tuned  Into  the  sector's  A/G  radio  fre- 
quency. Comparison  of  these  times,  as  measured  from  the  Los  Angeles 
Center  audio  tapes  against  the  average  sector  tLaes  reported  by  the 
facility  in  the  Busy  Day  Annual  Report  (1973),  found  little  difference 
between  the  data  sources.  The  times  shown  in  Table  12  were  obtained 
from  the  Atlanta  Center's  Busy  Day  Annual  Report  (1975). 

As  an  alternate,  the  average  transit  time  may  be  based  on 
the  time  between  aircraft  handoff  acceptance  and  initiation  and  obtained 
from  DART  printout  data.  But,  because  the  time  a controller  spends  on 
an  aircraft  is  closely  related  to  the  tisK  he  spends  "talking"  to  the 
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pilot,  the  average  time  or  frequency  is  considered  to  be  a more  meaning- 
ful measure  of  the  surveillance -time  requirement. 

4.3.4  Potential  Conflict  Work  Measurement 

As  in  the  case  of  routine  worr’oad  modeling,  the  two  essential 
parameters  pertaining  to  potential  conflict  workload  modeling  are: 

(1)  conflict-event  minimum  performance  times,  and  (2)  conflict-event 
frequencies.  We  discuss  separately  data  collection  requirements  of 
each  as  follows. 

4. 3.4.1  Conflict-Event  Minimum  Performance  Times 

Two  basic  types  of  potential  conflict  events  of  interest 
have  been  identified:  crossing  and  overtaking  conflicts.  In  both 

cases  the  component  tasks  are  dctection-and-asscssment  and  resolution. 
Curing  a field  experiment  conducted  -it  the  Los  Angeles  Center,  SRI 
spent  considerable  time  in  controller  interviews,  using  video  tape 
playbacks  of  PVD  displays,  to  ascertain  the  minimum  times  required  for 
these  two  tasks.  This  required  identifying  a conflict  event  and  then 
reviewing  with  the  controller  the  actions  required  to  recognize  the 
possibility  of  a conflict  and  the  reasons  and  methods  by  which  he  re- 
solved the  situation.  Typically,  the  controller  had  difficulty  in 
identifying  exactly  how  much  time  he  devoted  to  the  conflict  situation, 
but  we  usually  were  able,  with  sufficient  video  ta>'-.-  playback,  to 
estimate  the  times  at  which  he  became  first  aware  of  the  potential  con- 
flict, when  he  had  sufficient  information  to  determine  resolution  actions, 
and  when  the  appropriate  directives  were  issued  (by  means  of  A/C  com- 
munication) and  performed.  This  information  enabled  us  to  make  estimates 
of  the  task  times,  although  it  involved  considerable  video  tape  review 
during  the  off-site  data  reduction. 


Spot  checks  of  the  task  times  were  carried  out  during 
the  Atlanta  Center  field  experiment  by  briefly  reviewing  a few  potential 
conflict  situations  during  controller  interviews.  These  spot  checks, 
in  our  judgaent,  indicated  that,  except  for  some  minor  modifications, 
the  Los  Angeles  Center  task  times  were  applicable  to  the  Atlanta  Center 
operations.  The  minor  modification  reduced  the  detection-and-assessment 
task  for  overtaking  conflicts  at  the  Atlanta  Center  by  10  seconds  because 
this  facility  was  operating  with  ground-speed  display  while  the  Los  Angeles 
Center  was  not  during  our  data  observations.  The  ground-speed  display 
obviates  the  need  for  certain  A/G  speed  reports.  The  resulting  conflict- 
event  performance  times  are  summarized  •»  Table  13. 

TABLE  13 

CONFLICT  EVENT  PERFORMANCE  TIME  ESTIMATES 
ATLANTA  CENTER,  TWO-MAN  SECTOR  OPERATION 
SYSTEM  IA— NAS  STAGE  A BASE 


Conflict  Event 


Minimum  Task 
Performance  Time* 
(man-sec/ task) 


Detection 
and  Assessment 


Resolution 


Minimum  Event 
Performance 
Time 

(man-sec /event) 


Crossing 

Overtaking 


Based  on  data  collected  at  the  Los  Angeles  Center  and  observations  of 
Atlanta  Center  operations. 


To  determine  whether  conflict-event  task  time  adjustments 
are  necessary  for  subsequent  RECEP  modelings,  we  feel  that  future  field 
experiments  at  least  should  spot  check  task  times.  Furthermore,  given 
the  somewhat  inferential  nature  of  conflict  event  task  time  "measurement" 


as  described  above,  we  believe  that,  for  the  best  interest  of  modeling 
accuracy,  intensive  examination  of  conflict-event  times  should  be  carried 
out  wherever  possible.  However,  because  controller  interview-based 
task  assessment  is  a very  time-consuming  process  if  carried  out  on  a 
large  scale,  due  consideration  should  be  given  to  the  field  experiment 
cost's  Involved. 

A . 3 . 4 . 2 Potential  Conflict-Event  Frequencies 

We  have  used  as  part  of  the  Los  Angeles  and  Atlanta  case 
studies  mathematical  relationships  for  estimating  the  nunber  of  poten- 
tial crossing  and  overtaking  conflicts  in  a sector:  these  are  described 

in  Appendix  D.  The  mathematical  relationships  relate  frequency  of 
potential  conflicts  at  a conf 1 ict-point-to-aircraf t flow  rates,  the 
separation  minima,  and  sector  geometries.  In  using  these  relationships, 
we  found  fairly  close  correlation  between  the  calculated  frequencies 
and  the  number  of  potential  conflict  situations  reported  by  interview'd 
controllers.  For  example,  for  a l-hour  data  collection  session  during 
which  three  conflicts  were  identified,  the  conflict  equations  calculated 
3.7  conflicts/hour.  Although  thi3  is  not  a formal  validation  of  the 
conflict  frequency  calculations,  their  use  in  subsequent  field  experi- 
ments may  be  obtained  as  described  following. 

Important  information  regarding  potential  conflict  situa- 
tion control  procedures  is  obtainable  during  controller  interviews  with 
playback  of  the  PVD  video  tapes.  Controllers  will  identify  actual  con- 
flict points  that  command  their  attention.  These  conflict  points  are 
those  that  have  not  been  "procedural lizcd"  out  of  existence  fe.g., 
tunneling  routes  to  ensure  altitude  separation)  and  require  controller 
intervention  to  resolve  pairwise  conflicts  between  aircraft.  Further- 
more, the  controllers  could  provide  useful  insights,  based  on  their 
experience,  regarding  the  relative  intensities  of  crossing  and  overtaking 


conCl lets  at  different  points  and  reasons  for  conflict  situations  that 
may  not  bo  obvious  to  the*  observer  (c.g.,  speed  differentials  and  unique 
noise -abatement  procedures).  The  controller  interviews  should  also 
clarify  questions  regarding  the  in-trail  separation  procedures  applied 
at  various  locations.  For  example,  controllers  may  be  observed  to 
maintain  in  actual  practice  10  nmi  separations  in  enroute  airspaces, 
but  use  5 nmi  at  boundaries  with  terminal  facilities. 

This  kind  of  background  information  is  most  useful  for 
developing  a perspective  on  the  appropriate  applications  of  the  mathematlcal- 
conflict  models;  however,  additional  empirical  data  are  needed  to  support 
the  modeling  approach.  In  accordance  with  past  SRI  practice,  we  rec- 
ommend the  use  of  aircraft  ground-speed  displays  as  recorded  on  video 
tape  to  estimate  the  speed  classes  along  each  route.  Haps  obtained 
from  the  Center  are  useful  for  measuring  Intersection  angles  and  route 
lengths.  Also,  the  route  flow  rates  may  be  determined  from  the  video 
tape  recordings  or  or,  as  we  have  done  for  data-reduction  convenience,  by  ! 

inspection  of  flight-strip  data.  Further  details  describing  data  col- 
lection are  given  in  Appendix  E.  This  field  experiment  procedure  was 
used  at  the  Atlanta  Center  to  develep  the  potential  conflict-event 
frequencies  shown  in  Table  14. 

4.3.5  Sector  Traffic  Capacity  Estimation 

The  workload  thresholds  defined  during  the  Los  Angeles  Center 
case  study--66  man-min/hr  for  the  two -man  sector  team  and  48  man-min/hr 
for  the  R control ler--were  used  to  estimate  capacities  for  seven  sectors 
observed  at  the  Atlanta  Center.  The  team  and  R-controller  models  were 
simultaneously  applied  to  each  sector  to  determine  which  one  (team  or 
R controller)  constrains  sector  capacity.  The  workload  weightings 
determined  for  the  team  and  R controller  models  are  susssarlzed  in 
Table  15  for  each  sector;  these  weightings  are  based  on  the  data  presented 
in  Tables  8,  9,  and  l l through  14. 


73 


h . , . .ulilui  iiuiiMAi  diuinnuhitiluilli] . i 


TABLE  14 


ESTIMATED  FREQUENCY  OP  CONFLICT  EVENTS  PER  SECTOR 
ATLANTA  CENTER,  TWO-MAN  SECTOR  OPERATION 
SYSTEM  1A— NAS  STAGE  A BASE 


Sector 

Conflict  Event  Frequency  Factor 
( (confl icts/hr) /(alrcraft/hr)^) 

Overtaking 

High  enroute  (36) 

— 

4.8  X 10"3 

0.9  X 10-3 

Departure  transition  (37) 

4.4  X Iff3 

0.5  X 10~3 

Departure  (38) 
Arrival  f41) 

0 

2.7  X 10**3 

0.7  X 10~3 
6.4  X lO-3 

Arrival  transition  (42) 

3.5  X 10"3 

5.8  X 10"3 

Low  arrival  (46) 

6.6  X l(f3 

0.7  X 10-3 

Low  enroute  (52) 

5.3  X Iff3 

4.3  X 10'3 

The  capacity  estimation  procedure  was  to  calculate  the  workload 
for  successive  3-aircraf t/hour  increments  in  traffic  flow  and  to  inter- 
polate the  sector  traffic  capacity  corresponding  to  the  critical  work- 
load tn.'oshold.  (One  alternative  capacity  estimation  procedure  would 
be  to  -lot  workload  thne  versus  the  hourly  number  of  airci aft  through 
the  sector.  The  traffic  capacity  of  the  sector  could  then  be  determined 
by  graphically  finding  the  number  of  aircraft/hour  corresponding  to  the 
specified  upper  limit  on  workload  time.  Another  alternative  would  be 
to  solve  for  the  quadratic  equations  (listed  in  Section  IV-B)  for  N. 


I ft 


* 

l 


The  resulting  point  estimates  of  sector  capacities  obtained 
by  both  models  are  shown  in  Table  16.  Sectors  36,  37,  38,  41,  42,  and 
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Ccmt rol  1 er  citiaatM  of  sector  capacities  obtained  during  intervirtfi  at 
Atlanta  Center* 


*The  tin  nn  (Ms  capacity  Is  that  hourly  tnific  rate  that  gisrttn 
66  aannaltt/hy  of  team  routine  and  conflict  work. 


Ike  X controller  capacity  is  that  hourly  traffic  rate  that  generates 
48  Mn^-tain/hf  of  X controller  routiM,  surveillance,  and  conflict  work* 

K 

¥S»I  (Nttr  capacity  point  eatiwte. 


review  of  our  capacity  estimates,  so  Atlanta  Center  supervisory  staff 
member  evinced  general  agreement.  However,  he  conjectured  that  our 
capacity  point  estimates  for  Sectors  36  and  38  may  be  slightly  hi^i  by 
a few  aircraft/hour,  while  the  estimate  for  Sector  41  may  be  low  by 
about  five  aircraft/hour.  Because  the  use  of  these  estimates  was  to 
provide  a baseline  for  relative  productivity  of  enhanced  systems,  these 
small  capacity  differences  would  not  measurably  affect  subsequent  compari- 
sans. 


4.3.6  Alternative-  Sector  Hanning  Strategy  Analysis 

To  demonstrate  the  application  of  the  RECEP  methodology  to  the 
analyses  of  operations  that  could  not  be  observed,  let  us  examine  the 
modeling  of  three-man  sector  teams  for  the  Atlanta  Center  sectors.  The 
three-man  team  includes  an  R controller,  D controller,  and  a tracker  (T) 
controller. 

Three -man  sector  teams  were  not  in  operation  during  our  scheduled 
data  collection  periods;  modeling  of  their  task  activities  was  based  on 
controller  interviews  and  observations  without  data  collection  of  three- 
man  operations.  Controllers  reported  that  this  manning  strategy  requires 
the  T controller  to  work  closely  with  the  R controller,  and  the  D controller 
operates  in  a less-reactive  role.  The  T controller  performs  the  time- 
critical  FDP/RBP  manual  operations  in  reaction  to  R-controlier  actions 
and  assists  in  flight-strip  processing.  The  0 controller  performs  such 
of  the  interphone  communications  and  the  less  traffic -reactive  FDP/ROP 
manual  operations  (e.g.,  flight  data  estimate  updating)  and  flight-strip 
processing  (e.g.,  sequencing/ removal) . We  note  that,  at  the  Atlanta 
Center,  the  T controller  is  physically  situated  between  two  adjacent 
sector  consoles  so  that  he  can  use  both  sectors*  FOP/ RDP  keyboards  to 
manual ly  initiate  and  accept  handoffs  between  the  two  sectors.  However, 
in  this  so-called  ■’half-man"  operation,  his  primary  function  during  limey 


periods  Is  to  directly  support  only  one  of  the  two  R controllers,  thus 
effectively  being  integrated  into  the  control  operations  of  one  sector 
team. 

Because  the  R-T  control  operation  is  similar  in  structure 
to  the  R-D  team  operation  of  the  two-man  sector  manning  strategy,  the 
66  man-min/hr  workload  limit  was  assumed  to  apply  to  the  R-T  team.  The 
corresponding  R-T  team  routine  event  performance  times  are  shown  in 
Table  17.  Tasks  performed  by  the  D controller  were  not  included  in 
this  model  formulation  as  his  workload  would  not  constrain  traffic 
capacity. 

The  48  man-min/hr  workload  limit  was  applied  to  the  R controller. 
R-corcroller  task  allocations  are  similar  to  those  described  for  the 
two-man  operation  except  for  transfer  of  some  traffic  structuring  flight- 
strip  processing  and  FDP/RDP  operations  to  the  T controller.  We  assumed 
that  the  T controller  will  take  over  the  flight-strip  processing  associ- 
ated with  the  altitude  instruction  and  transponder  code  assignment  events 
(in  conjunction  with  the  FDP/RDP  manual  tasks  required  for  these  events), 
as  well  as  the  FDP/RDP  manual  operations  for  pointout  acceptance-data 
block  suppression  and  data  block/ leader  line  offset  events  (which  par- 
allel his  handoff  activities). 

Conflict  processing  and  surveillance  work  would  be  the  same 
as  those  described  for  two-man  sector  operations.  Routine-event  fre- 
quencies would  be  as  shown  in  Table  8,  and  workload  weightings  may  be 
calculated  in  the  same  way  as  that  for  the  R and  D operations. 

Sector  traffic  capacity  is  the  traffic  flow  rate  that  generates 
the  quantity  of  work  corresponding  to  the  two-man  R-T  controller  team 
(66  man-min/hr)  or  R controller  (48  man-min/hr)  workload  threshold, 
whichever  is  critical.  Under  three-man  sector  operations,  the  capacities 
of  Sectors  36,  37,  38,  41,  42,  46,  and  52  are  44,  42,  55,  32,  40,  37, 
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TABLE  17 


R-T  TEAM  ROUTINE  EVENT  MINIMUM  PERFORMANCE  TIME  ESTIMATES 
ATLANTA  CENTER,  THREE-MAN  SECTOR  OPERATION 
SYSTEM  IB— NAS  STAGE  A BASE 


Control  Fvent  D«.»cr  ipt  ion 


Minimi*  Task  Perfornattce  Tit** 
(aan-aec/task) 


, Event. 

1 function 


Control 

jurisdiction 

trantfar 


IUhIc  Event  and 
SuppU'Drntal  Event 


Mandoif  acceptance 
Flight  data  update 
Interaector  coordination 
New  flight  ttrlp  preparation 
Handoff  initiation-automatic 
Manual  lnitlatlon-atlent 
Interaector  coordination 


Initial  pilot  call-in 
Flight  data  altitude  insert 
Altitude  Instruction 
Flight  data  altitude  aatendtaent 
Interaector  coordination 
Heading  Instruction 
Flight  data  aaendaant 
lotertector  coordination 
Speed  instruction 

Interaector  coordination 
Altineter  aettlng  Instruction 
Runway  asalgnaent  instruction 
Pilot  attitude  report 
Plight  data  altitude  insert 
Pilot  beading  report 
Pilot  speed  report 
Traffic  advisory 
Transponder  code  aaalgnaMOt 
Plight  data  code  mend  sent 
Miscellaneous  A/C  coordination 
Frequency  change  instruction 
Intaraector  coordination 


Altitude  revision 

Plight  data  altitude  asendaeot 

Interaector  coordination 
Routa/I'esdlng  revision 
Plight  data  routs  anendaant 
Interaector  coordination 
Speed  revision 
Clearance  delivery 
Miscellaneous  pilot  request 


£H  1 i jybaksAwiiniuiMsaadis  muss 


37  aircraft/hr,  respectively.  In  each  case,  the  R controller  (48  man- 
min/hr),  limits  capacity. 

4.4  RECSP/ATF  INTERFACE 

RECEP  estimates  the  traffic  capacity  of  individual  sectors,  and 
ATF  estimates  aircraft  delays  for  a multisector  environment.  The  ATF 
model  identifies  situations  in  which  individual  sectors  are  about  to  be 
overloaded  and  delays  aircraft  in  ocher  sectors  to  prevent  overloadings. 
The  interface  between  RECEP  and  ATF  is  effected  by  transforming  RECEP 
capacity  estimates  into  certain  ATF-raodeling  parameters;  these  parameters 
define  overloading  situations  and  are  determined  using  the  input  data 
needed  to  begin  an  ATF  formulation. 

ATF  uses  three  parameters  (sector  workload  threshold  and  two  work- 
load coefficients),  to  assess  sector  traffic-handling  capabilities.  All 
can  be  obtained  directly  by  the  RECEP  technique.  The  sector  workload 
threshold  is  66  or  48  man-min/hr  depending  upor  which  model  establishes 
capacity.  The  first  workload  coefficient  is  the  sum  of  the  linear  con- 
stant terms  in  the  RECEP  model  being  used  and  the  second  coefficient  is 
the  sum  of  the  constants  associated  with  the  quadratic  terms.  Multiply- 
ing the  workload  coefficients  respectively  by  the  number  of  aircraft  and 
number  of  aircraft  squared  in  the  sector  during  a specific  time  increment 
(e.g. , 1-min)  obtains  the  total  sector  workload  for  that  time  increment. 
ATF  constrains  sector  (arc)  entries  to  assure  that  the  total  sector 
workload  during  che  time  increment  does  not  exceed  the  workload  threshold. 
This  prevents  the  occurrence  of  workload  surges  of  magnitudes  exceeding 
the  average  long-term  workload  limit  specified  by  the  threshold  valua. 

That  is,  the  greatest  rate  at  which  a sector  team  is  allowed  to  work  is 
66  man-min/hr  for  any  l-min  increment  (during  which  l.i  man-mln  of 
hourly  work  are  expended),  and  the  R controller  is  limited  to  a work 
rate  of  48  man-min/hr  during  any  -min  increment. 

HO 


The  workload  coefficients  are  calculated  so  that  an  aircraft's 
cumulative  workload  contribution  is  distributed  over  its  expected  un- 
delayed sector  transit  time.  However,  ATF  allocates  workload  by  delaying 
aircraft  in  upstream  sectors.  Additional  work  involved  in  delaying 
actions  (e.g.,  vectoring,  speed  restrictions)  is  induced  on  the  upstream 
sector  team.  This  Induced  work  has  not  been  accounted  for  in  the  cal- 
culation of  the  workload  coefficient.  Because  of  the  natural  implemen- 
tation of  planning  control  by  in-trail  restrictions,  it  may  be  assumed 
that  induced  delay  work  corresponds  to  an  additional  amount  of  "normal" 
(i.e.,  routine  conflict  and  surveillance)  work.  Therefore,  the  workload 
coefficient  also  could  respresent  the  total  workload  contribution  of  an 
aircraft  while  it  is  being  delayed.  This  approach  was  used  to  model 
multisector  operations  for  the  Lns  Angeles  Center  and  Atlanta  Center. 


4.:;  RECEP  DATA  BASE  UPDATE  AMD  MODEL  VERIFICATION 

The  RECEP  data  base  update  and  model  verification  are  required 
periodically  to  maintain  its  validity  as  a reliable  measuring  and 
predicting  tool. 

4.5.1  RECEP  Data  Base  Update 

Although  the  RECEP  data  bases  that  have  been  used  for  the 
Los  Angeles  study5  and  the  Atlanta  ;.tudy3  are  adequate  for  the  two 
centers  and  it  is  also  possible  that  the  task  minimum  times  of  the 
current  data  bases  may  be  equaily  applicable  to  other  centers  as  well, 
it  is  nevertheless  desirable  to  perform  a two-  or  three-dav  field  test 
at  the  same  sites  ("quick  look")  to  recalibrate  the  routine  and  conflict 
workload  estimates  prior  to  the  application  of  RECEP  to  a new  center. 


4.5.2  Model  Verification 


The  purpose  of  this  test  is  to  compare  RECEf  estimates  vith 
suae  other  field  measures  estimating  workload  and  traffic  capacities 
(e.g. , peer  observations  of  workpace,  voice  channel  utilisation,  air- 
craft p,  oximity  weighting)  to  verify  the  realism  of  the  RECEP  technique. 

The  verification  will  probably  involve  two  stages.  The  first 

one  is  an  initial  comparison  between  the  RECEP  workload/aircraft  loading 

function  for  each  sector  and  the  workpace/aircraft  loading  functions  (as 

measured  in  the  field).  In  the  event  the  two  functions  do  not  coincide, 

then  a second  stage  would  be  necessary  that  involves  a recalibration  of 

the  RECEP  estimates  to  be  more  closely  aligned  with  field  measures. 

Some  detailed  approaches  on  RECEP  data  base  update  and  model  verification 

★ 

have  been  suggested  by  TSC  and  are  described  in  Appendix  G.  However, 
this  procedure  has  not  been  tested;  therefore,  its  effectiveness  is  not 
known  at  this  time. 

The  update  and  verification  procedures  are  primarily  for 
repetition  routine-event  workloads.  For  conf lict-event  workloads  a direct 
comparison  may  not  be  feasible;  it  is,  however,  possible  to  compare 
sectors  with  similar  conflict  complexities  and  volumes. 


In  connection  with  this  requirement 'the  Transportation  Systems  Center 
has  developed  a software  methodology  for  rapid  scanning  the  workpace  and 
Work  Activity  tapes  to  produce  the  followir.g  information: 

To  select  those  sectors  and  time  intervals  that  have 
experienced  maximum  traffic  load  as  «tay  be  specified  by  the 
input  search  parameters. 

To  compute  the  Work  Activity  actual  task  times  (e.g.,  for 
interphone  communication,  RDP/RDP  operations,  and  flight 
strip  processing)  in  order  to  compare  these  times  with 
RECEP  estimates.  A description  of  this  sKth^dology  is 
given  in  Appendix  P. 
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5.  DESCRIPTION  OF  THE  A III  TRAFFIC  FLOW  MODEL 


5.1  MODEL  OVERVIEW 

The  ATE  model ’is  a "flow-model"  in  which  individual  aircraft  are 
aggregated  in  terms  of  flow  rates  along  routes.  The  flow  rates  are  used 
to  define  a uniform  distribution  of  arrival  times  at  the  route  origins 
according  to  a Poisson  process.  The  route  arrival  times  for  each  air- 
craft (or  group  of  aircraft)  in  turn  define  expected  aircraft  counts 

* 

along  each  at:c  as  described  below. 


Real  World  Quantity 


Network  definition 
Sectors 
Arcs 
Routes 

Arc  transit  times 

Aircraft  arrival  rates  for  route  k for  the  tine 
period  T (c.g.,  20  min) 

Sector  workload  approximation 

(a  function  of  the  number  of  alrcraftr  n,  sector  m) 
Sector  workload  maximum  for  each  sector 


Variable  Name 
(if  applicable) 


Congestion-relief  strategy 


rk(T) 


WL  <n> 
n 


3 or  C 


For  each  route  (made  up  of  arcs  connecting  node  1 to  node  j)  the 
uniformly  distributed  arrival  rate  r^i')  defines  an  arrival,  distribution 


Portions  of  this  discussion  have  been  abstracted  ft om  Wong,  Peter  J., 
ct  al.t  "SRI's  Air  "Vaffic  Flow  Model,"  Paper  presented  at  £he  1976 
Sumner  Computer  Simulation  Conference,  July  1976  (Proceedings  as  yet 
unpublished). 
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a,,(t)  f or  the  first  and  successive  arcs  on  the  route. 

ij 

departure  distribution  is  also  calculated  according  to 


An  .‘xpoctud 
the  equation: 


(t  + t ) * 


where, 


(t) 

(t) 


arrivals  on  arc  for  time  t. 
departures  on  arc  for  time  t. 


* arc  transit  time. 


This  departure  "schedule"  is  modified  as  explained  below  by  the 
load-balancing  algorithms.  For  each  time  increment,  At,  and  time,  t, 
the  program  calculates  the  number  of  aircraft  on  the  arc,  as  follows 


•*ij(t)  - a^(t)  " ^(t)  + 

The  ATF  model  is  characterized  by  two  parts.  The  first  is  an 
accounting  system  to  translate  arrival  rates  into  aircraft  counts  and 
calculate  expected  and  act'ial  instantaneous  counts  of  aircraft  on  each 
arc  and  in  each  sector.  The  second  part  monitors  and  alters  the  expected 
flows  at  each  At  according  to  two  congestion-relief  schesres.  Aircraft 
flcvs  ate  altered  whenever  a sector  became  overworked.  A secondary  cause 
for  delay  can  be  excess  aircraft  (over  an  input  suiximum)  on  the  route. 

Let  n be  the  number  of  aircraft  in  a sector  at  time  t defined  as  follows: 

n -2>tj(t> 
all  arcs  in  sector 
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Then  for  each  sector: 

2 

WL  In)  - k.n  ¥ k n 

a A B 

■k 

where  and  k^  a*>.  constants  whiwW  are  calculated  using  KECEP. 

The  congestion-relief  logic  Is  applied  whenevei  a sector  fcculd  be- 
come congested  if  the  expected  flows  calculated  for  the  present  simula- 
tion time  were  allowed.  The  congestion-relief  schemes  treat  each  sector 
differently  depending  upon  whether  it  is  congested  or  uncongested,  as 
defined  below. 

A sector  is  defined  as  congested  if: 


WL  (n) 

tu 


> w 


max.m 


W is  defined  as  sector  workload  capacity  according  to  RECEP.  A 
sector  is  in  the  uncongested  state  if  its  workload  la  such  that  aircraft 
can  be  delayed  from  leaving  the  sector  without  ita  workload  belrg 
greater  than  the  maximum.  The  moat  congested  sector  is  defined  to  be 
the  congested  sector  that  has  the  greatest  workload.  Similarly,  the 
least  congested  sector  is  defined  to  be  the  uncongcstcd  sector  that  nas 
t»;c  least  workload.  Once  sector  status  is  established  for  the  present 


* 

As  discussed  in  Sections  XV-A&D,  k^  and  k^  are: 
(1)  For  team  RECEP  model 


#.  * k 

A 1 

* * k f k 

8 2 3 


(2)  For  the  R-concroller  REC*P  mo  !il 

k « k(  + ct 
A 1 S 


kB  * + k3 


83 


tliPlilulr.  lii  Jinli  >J.  Jhiif.,  ill  111  ■ Wflifltl,  illfir 


system  time,  t,  the  expt-cted  flows  are  readjusted  through  the  mechanism 
of  "delaying"  aircraft  from  entering  congested  sectors.  There  are  two 
strategies  presently  available  for  imposing  this  delay. 

The  first  strategy,  B,  can  be  titled  "Route  Delay  Priority  Based 
on  Instantaneous  Loading."  The  rationale  for  the  basic  structure  of 
this  scheme  Is  aa  follows.  For  each  fixed-time  increment,  At,  wc  pick 
the  most  congested  sector  to  try  to  relieve  congestion.  Uc  off-load 
aircraft  to  the  neighboring  sectors  that  feed  the  congested  sector  with 
the  most  net  activity,  beginning  with  the  sector  that  feeds  the  most 
net  activity.  Net  activity  is  defined  as  gross  entries  from  the  feeding 
sector  minus  gross  departures  to  the  feeding  sector.  We  do  this  until 
the  congested  sector  is  relieved.  If,  based  upon  net  activity,  tie  cannot 
find  a feeding  sector  where  aircraft  can  be  delayed  without  causing  con- 
gestion, we  pick  a new  feeder  sector  with  the  most  feeding  traffic 
(grots  entries).  Traffic  is  dels  ed  in  this  sector  up  to  the  number  of 
aircraft  that  are  expected  to  feed  the  feeder.  We  repeat  the  process 
until  the  congested  sector  ir  relieved.  Once  the  most  congested  sector 
is  processed  ve  repeat  the  ope ratio?  for  the  next  most  congested  sector. 
This  algorithm  tends  to  push  congestion  along  the  major  routes  to  the 
boundary  of  the  center. 

The  second  strategy,  C,  is  Jescribed  as  a "Present  Route  Priority." 
The  rationale  for  this  scheme  is  straightforward.  The  priority  list 
of  routes  on  which  delays  should  be  distributed  in  the  event  congestion 
occurs  Is  set  beforchaiiu  in  accordance  with  the  actual  procedures  used 
at  the  enroute  or  terminal  site  being  modeled.  In  this  scheme  we  pick 
the  most  congested  sector  snd  search  the  route  priority  list  for  the 
highest  priority  route  passing  through  the  sector.  Delay  it  assigned 
to  the  sector  upstream  on  this  route.  We  continue  the  route  search 
until  congestion  Is  relieved  or  there  are  no  more  toute*  on  the  priority 
list.  The  whole  operation  is  repealed  for  the  next  most  congested 
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sector  until  all  congestion  is  relieved.  Priorities  are  assigned  to 
imitate  the  procedures  in  actual  use  for  flow  management  in  the  center 


Schesm  C is  the  preferred  congestion-relief  strategy  for  present 
operations.  However,  because  of  the  possibility  of  assigning  route 
priorities  wrong  it  should  be  applied  with  care.  Problems  can  occur  if 
two  adjoining  sectors  are  both  congested  and  the  preset  route  priovities 
are  such  that  the  two  congested  sectors  delay  traffic  back  and  forth. 

In  most  cases,  only  one  of  two  routes  passing  through  adjoining  sectors 
in  opposite  directions  should  be  assigned  a delay  priority.  In  all 
cases  thus  far  studied,  the  above  situation  has  not  been  encountered. 

A secondary  cause  of  delay  which  is  independent  of  the  congestion- 
relief  strategy  results  from  an  excess  of  aircraft  on  the  route  over  a 
preset  maximum.  This  type  of  dela,  is  imposed  at  the  route  origin 
whenever  an  expected  entry  would  cause  the  count  of  aircraft  on  the 
route  to  exceed  the  maximum.  An  exmaple  of  a possible  area  for  applica- 
tion of  this  feature  is  provided  in  the  next  section. 

The  primary  functional  output  from  the  ATP  model  is  amount  of  de- 
lay. Delay,  for  the  purpose*  of  the  model,  is  defined  as  an  additional 
wait  of  one  time  increment  due  to  individual  sec cor  saturation  or  excess 
aircraft  on  the  route.  The  maaber  of  delays  aailtlplied  by  the  time 
increment,  At,  is  excess  transit  time.  Excess  transit  time  is  time  in 
excess  of  inputed  arc  transit  times  (t^).  System  delay  is  the  average 
of  the  delays  for  all  aircraft  within  the  system  (Including  those  de- 
layed on  the  boundary)  for  the  period  of  operation.  The  traffic  load 
is  also  outputed  in  terns  of  number  of  aircraft  in  various  parts  of  the 
network  (i.c. , entering/exiting  each  route,  sector,  and  arc).  A third 
output  is  Instantaneous  sector  workload.  All  output  is  p in ted  accord- 
ing to  the  print  frequency  specified  at  input.  The  fretuency  is  ex- 
pressed in  time  increments  per  print  cycle. 
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The  air  traffic  flow  Model  is  thus  a Model  that  provides  the  analyst 
with  several  estiMates  of  the  performance  of  a multisector  environment 
based  upon  sector  workload  capacity  and  traffic  loads. 

The  ATF  Model  is  written  in  FORTRAN  IV  language  and  currently  con* 
tains  approximately  1,000  statements.  Based  on  recent  experience,  an 
average  case  (10  sectors  with  500  aircraft  for  a 9-hour  opt  ation)  takes 
about  20  to  30  seconds  central  processor  time  on  SRl's  CDT  6400  computer 
system.  Altogether  (program  plus  data  arrays)  approximately  50,000 
octal  core  locations  are  required.  This  requirement  is  based  on  a 
potential  network  of  up  to  40  sectors  and  60  route;  .long  with  their 
corresponding  traffic  flows  at  capacity. 

The  Model  is  designed  to  run  on  batch-processing  Mode.  However, 
a remote  job- submission  and  teradnation  procedure,  eluding  some  limited 
on-line  terminal  input  and  output  capabilities  is  available.  The 
beginnings  of  tome  interactive  design  features  have  also  been  incorporated 
in  the  cede. 

5.2  ASSUMPTIONS  AND  LIMITATIONS 

The  basic  assumption  made  in  formulating  the  Air  Traffic  Flow 
Model  is  that  average  fl~w  rates,  rather  than  independent  aircraft 
following  calculations,  are  sufficient  for  capacity  estimates.  This 
simnllfying  assumption  dictates  much  of  the  remaindt.  of  the  model  de- 
sign. Individual  flight  paths  can  be  aggregated  into  route  representa- 
tions because  the  sector  entry  and  exit  times  for  the  aircraft  (not 
their  position  within  each  sector)  are  the  variables  of  interest.  It 
is  assumed  that  all  aircraft  in  a particular  sector  have  the  same  transit 
time.  Each  arc  along  a route  is  assigned  a transit  time  at  input  and 
all  aircraft  transit  the  arc  in  the  assigned  time.  The  arrival  rate 
for  individual  aircraft  at  the  origin  of  each  route  is  specific  d in 
terms  of  a flow  rate.  Actual  arrival  times  for  the  specified  period 
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are  randomly  generated  according  to  a Poisson  proem  s.  Two  or  sore 
aircraft  which  errive  in  the  seme  time  increment  are  treated  as  a set 
for  computational  purposes.  Thus  computer  run  ttr  2 depends  relatively 
little  upon  the  number  of  aircraft  unless  congest  on  relief  is  required 

Congestion  relief  is  applied  to  balance  traffic  loads  whenever  a 
sector  is  congested.  A secondary  cause  for  delay  can  be  excess  air- 
craft in  a route  above  a maximum  (specified  as  a program  input).  The 
capacity  of  a sector  is  defined  to  be  constant  according  to  the  value 
calculated  using  RCCBP.  There  are  no  provisions  for  allowing  a sector 
workload  to  exceed  the  constant  capacity  for  short  periods.  The  program 
will  print  out  warnings  and  stop  processing  (depending  upon  the  run 
option)  whenever  certain  delay  sMxima  are  exceeded.  Theae  maxima,  which 
are  set  at  run  time,  are  maximum  delay  at  all  route  origins,  msxlmum 
delay  in  all  sectors,  and  maximum  average  aircraft  delay.  Individual 
routes  and  sectors  are  coshered  to  the  maximum  one  by  one. 

We  have  said  that  by  definition  one  delay  Is  counted  each  time  am 
aircraft  is  restrained.  We  sake  the  following  additional  definitions 
in  terms  of  the  program  output.  Ctmwlatlve  Aircraft  Delay  count  is  the 
total  delay  count  for  all  aircraft  in  the  system.  Including  those  trying 
to  enter  and  deUy*d  at  origin.  Average  Aircraft  .Delay  is  the  cumulative 
delay  divided  by  the  number  or  aircraft  which  Have  entered.  To  obtain 
the  system  delay  (as  used  to  compere  different  automation  systems)  we 
run  the  ATF  model  to  completion  without  using  the  swutimum  delay -stopping 
option.  The  Average  Aircraft  Delay  figure  becomes  the  total  delays 
divided  by  the  total  aircraft  to  enter  (where  po  additional  aircraft  are 
waiting  to  enter).  If  the  time  Increment  is  ras*  minute,  the  figure 
is  in  minutes.  System  delay  is  this  figure  'sinus  the  traffic  and  delays 
generated  during  an  initial  system  loading  period  amt  final  unloading 
period  as  described  below. 


89 


iJJJSi! 


flggf  ..^uK'^gggg^ggggsg 

At  the  start  of  a simulation  run  there  is  no  traffic  in  the  network. 
The  initial  traffic  load  results  from  running  the  system  for  some  load- 
ing period  prior  to  the  portion  of  time  actually  used  for  analysis. 

For  example,  in  past  applications  the  model  has  been  run  for  nine  hours 
of  simulation  input.  The  effects  of  the  first  hour  of  traffic  have  to 
be  factored  out  of  the  output  statistics  for  purposes  of  analysis.  Also 
the  system  delay  figure  is  calculated  after  all  input  traffic  has  been 
allowed  to  enter. 

For  some  applications,  the  above  procedure  may  not  be  completely 
satisfactory.  It  might  be  desirable  to  factor  out  the  effects  of  delay 
at  origins  automatically  and  before  all  origin  delays  have  entered. 

To  do  this,  the  present  output  should  be  modified.  The  average  aircraft 
delay  figure  must  become  the  cumulative  delay  divided  by  the  number  of 
aircraft  that  have  entered  plus  the  number  waiting  to  enter  but  delayed 
at  the  origin.  When  the  model  is  run  until  there  are  no  aircraft 
waiting  to  enter,  the  present  average  aircraft  delay  and  the  above  figure 
will  be  equal. 

The  limitations  in  application  of  the  Air  Traffic  Flow  model  can  be 
considered  in  light  of  the  above  assumptions.  First,  because  there  is 
only  one  arc  transit  time,  if  an  airspace  with  a large  mix  of  aircraft 
velocities  and  trajectories  is  being  modeled  the  results  must  be  used 
carefully.  Statistical  distributions  for  arc  transit  times  could  be 
implemented  rather  easily,  however,  if  this  becomes  important.  It  would 
be  done  b>  sampling  a distribution  whenever  aircraft  arc  exit  times  are 
stored  in  the  code.  In  controlled  airspace,  velocities  of  all  aircraft 
on  a route  in  a sector  tend  to  be  the  same.  This  minor  limitation  is 
also  overcome  to  some  extent  because  RECEP  conflict  models  are  sensitive 
to  variabilities  in  traffic  and  thus  enter  ATF  calculations  through  the 
sector  capacity  estimate.  A second  limitation  to  the  ATF  application  is 
the  lack  of  re-routing  capability.  (That  is,  the  congestion  relief 
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sch'-«?B  do  not  re-route  aircraft.)  If  extensive  delays  are  being  en- 
countered in  some  part  of  the  system  it  is  not  possible  at  the  present 
time  to  divert  aircraft  to  a less  congested  area.  SRI  has  used  the 
methods  described  here  to  model  the  enroute  environment.  Application 
to  a TRACON  airspace  requires  the  definition  of  an  interface  to  the 
tower.  It  is  believed  that  the  tower  constraints  may  be  represented 
by  an  adjustment  of  the  boundary  flow  rates  in  accoriancf.  with  gate 
schedules,  runway  taxi  conditions,  runway  restrictions,  etc. 

5.3  MODEL  COMPONENTS 

This  section  contains  a description  of  the  conventions  used  in  the 
ATF  model  on  a designer's  Level.  It  is  intended  to  provide  a user  some 
insight  into  the  model  logic  and  thus  help  him  avoid  possible  pitfalls 
in  the  use  of  the  tool. 

As  stated  previously,  the  model  calculates  an  expected  flow  and 
congestion  status  for  each  sector  at  each  time  increment.  Aircraft  are 
delayed  from  this  expected  movement  if  congestion  exists.  The  system 
tables  are  updated  based  upon  the  results  of  the  delay  actions. 

The  remainder  of  this  section  will  deal  with: 

• The  internal  table  structure  and  its  relation  to  the 
abstract  network  and  traffic  movement. 

• 'The  traffic  generation  logic. 

• Expected  traffic  movement  calculations. 

• Conditions  causing  the  imposition  of  delay  and  the  delay 
strategies  available. 

The  abstract  Air  Traffic  Flow  network  has  been  described  theoretically 
as  a series  of  nodes,  arcs,  routes,  and  lectors.  A node  is  defined  to 
be  the  point  where  an  arc  begins  or  terminates  at  a sector  boundary. 

Thus,  if  we  define  an  arc  in  terms  of  its  origin,  transit,  and  destination 
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sectors  we  implicitly  define  the  nodes.  The  ATF  model  employs  this 
logic  to  eliminate  the  need  to  input  and  store  a node  lsit.  Routes  are 
defined  as  a series  of  arcs  beginning  and  ending  at  the  airspace  boundaries. 
For  example,  when  an  enroute  area  is  being  modeled,  the  boundaries  con- 
sist of  terminal  and  enroute  sectors  outside  the  multisector  area  of 
interest.  Hie  arcs  must  be  connected.  That  is,  if  arcs  1 and  2 make 
up  a route,  arc  1 must  end  in  the  sector  that  arc  2 transits  and  arc  2 
must  begin  in  the  sector  that  arc  1 transits.  Because  there  arc  no 
nodes  internal  to  a sector,  the  logic  requires  that  merging  and  diverging 
of  routes  be  treated  as  completely  separate  routes  within  each  sector. 

For  example,  if  two  paths  1 and  2 merge  (or  diverge)  within  a sector 
into  (or  from)  path  3,  it  must  start  (or  end)  at  the  sector  boundary. 

A route  is  unidirectional  to  simplify  the  logic.  If  bidirectional 
traffic  is  encountered  (obviously  with  altitude  separation)  then  two 
routes  must  be  defined.  Each  arc  on  the  route  is  assigned  a transit 
time  in  the  same  units  as  the  time  increment. 

For  each  sector,  workload  maximum  and  constants  assigned  at  input 
must  be  maintained.  Finally,  the  traffic  flow  at  the  origin  of  each 
route  is  required.  The  flow  is  used  to  calculate  specific  aircraft 
(or  group  of  aircraft)  arrival  times  as  described  later.  The  expected 
exit  times  for  each  aircraft  (or  group),  as  described  in  Section  V-A 
(Model  Overview)  is  also  calculated  and  stored. 

The  above  logic  defines  a requirement  for  four  kinds  of  tables: 
arc  tables,  route  tables,  sector  tables,  and  traffic  tables.  These 
tables  contain  the  network  structure  information  described  above  and 
all  system  status  information.  To  provide  for  the  use  of  dynamic  run 
time  memory  allocation,  three  of  these  tables  are  contained  in  a single 
internal  array  called  LINK.  They  are  the  arc  table,  route  table,  and 
expected  aircraft  exit  time  table,  in  that  order.  Other  arrays  used 
as  pointers  are  maintained  along  with  these  tables.  The  sector 
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information  is  stored  in  a series  of  arrays  because  three  of  the  variables 

(WL  , K , K)  are  real  while  sector  counts  and  delay  counts  are  integer 
m A B 

values* 

Traffic  flows  are  defined  for  specific  contiguous  tiam  periods. 

For  example,  if  five  aircraft  are  to  arrive  on  route  1 from  the  start 
of  the  simulation  until  the  end  of  60  time  increments  (say  60  minutes 
if  time  is  in  minutes),  then  the  next  set  of  arrivuls  might  be  defined 
for  time  61  through  120. 

The  actual  arrival  times  for  each  of  these  flow  periods  are  generated 
according  to  a Poisson  process.  For  example,  if  we  had  a flow  of  five 
aircraft  within  60  time  increments,  a pseudorandom  uniform  distribution 
is  sampled  five  times  and  actual  arrival  times  for  the  five  aircraft 
are  calculated  from  the  sample  values. 

To  assure  that  arrival  distributions  for  lower  traffic  level  are 
contained  (explicitly)  in  higher  traffic  distributions  the  random- 
number  generator  is  seeded  with  a particular  start  value.  For  example, 
suppose  for  traffic  level  1 there  were  four  aircraft  arriving  on  route 
number  11.  The  pseudorandom  number  generator  would  be  seeded  and  then 
sampled  four  times  for  route  11.  If  the  same  route  had  eight  arrivals 
for  traffic  level  2,  we  would  start  with  the  same  seed.  Thus,  we 
obtain  the  four  original  arrival  times  plus  the  four  new  tines  for 
the  total  of  eight  aircraft. 

Expected  traffic  movements  for  each  arc  are  maintained  as  arc 
exit  times  for  each  aircraft  (or  group)  in  the  traffic  movement  table. 

At  each  time  increment  all  delayed  and  any  expected  undelayed  aircraft 
arc  allowed  to  move.  The  movement  table  is  not  updated  at  this  time 
because  if  it  were,  and  delay  is  imposed,  movements  would  have  to  be 
updated  to  reflect  the  delay.  Instead  the  program  logic  waits  until  the 
next  time  increamnt  to  store  sovement  times  and  counts  for  all  aircraft 
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that  were  not  delayed.  Any  delayed  aircraft  are  counted  as  part  of 
the  delay  queue. 


Sector  loads  in  terms  of  number  of  expected  aircraft  and  workload 
are  calculated  next  and  stored  in  sector  tables.  Sector  workload  and 
its  relation  to  capacity  are  the  primary  cause  for  delay.  A secondary 
cause  can  be  the  number  of  aircraft  allowed  on  a route.  These  two  type;: 
of  delay  have  been  discussed  previously. 
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A secondary  cause  for  delay,  as  previously  described,  can  be  an 
excess  (over  a preset  maximum)  of  aircraft  on  a route.  Suppose  for 
example,  that  a terminal  area  is  being  modeled.  The  general  avaiation 
traffic  is  minimum  so  no  sector  in  overworked.  The  physical  airspace 
and  procedures  along  the  pr Leary  arrival  route,  however,  restricts  the 
number  of  aircraft  that  can  be  handled.  The  program  will  delay  aircraft 
at  the  origin  to  avoid  allowing  an  unrealistic  number  of  aircraft  on  the 
route.  If  this  type  of  delay  is  not  desired,  the  input  maximum  for  each 
route  should  be  set  to  some  high  number. 

This  section  has  provided  a description  of  the  logic  behind  the 
ATF  model.  Specifically  the  logic  for  network  formulation  and  related 
program  Internal  table  structure  have  been  discussed.  Traffic  generation 
logic,  expected  movement  calculations,  sector  loading  and  workload  cal- 
culations have  been  covered.  Two  conditions  causing  the  imposition  of 
delay  were  discussed  as  well  as  the  choice  of  congestion  relief  strategies 
available  for  imposition  of  delay  under  sector-overload  conditions. 


1 
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5.4  INPUT  AND  OUTPUT  SPECIFICATIONS 

The  input  and  output  information  for  the  ATF  model  are  covered  in 
this  section.  The  discussion  is  Intended  to  provide  the  analyst  with 
an  understanding  of  the  real-world  correspondence  with  each  data  element.  ~ 
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The  .ypes  of  input  data  nay  be  classified  into  the  lot lowing 


groups: 


• Network  composition  (s&itors,  routes,  and  arcs) 


• Traffic  flow  parameters 


« Sector  workload  maximum 


• Sector  workload  coefficients 


• Conge st ion -relief  strategy. 


The  following  sections  will  give  descriptions  on  each  of  the  above 


input  groups  with  particular  mention  of  the  relationship  between  the 
parameters  and  the  source  of  field  data  from  which  the  computer  input  is 
developed. 


5.4.1  Input 


5.4.1. I Network  Composition  and  Traffic.  Flow 


In  the  previous  section  we  described  the  logic  incorporated 
for  inputing  network  structure.  We  saw  that  we  use  Implied  nodes  for 
input  to  the  model.  We  also  explained  the  unidirectional,  nature  of  each  , 
logical  route  and  the  connectivity  requirements  for  arcs  comprising  the 
route.  Here  we  will  provide  an  example  and  details  as  to  how  a real- 
world  airspace  can  be  abstracted.  Figure  3 shows  a multisector  study 
area  for  the  Atlanta  Enroute  Air  Traffic  Control  Center.  This  figure 
and  a large  portion  of  this  section  have  been  abstracted  from  an  as 
yet  unpublished  study  conducted  by  SRI  in  They  are  included  in 

full  here  for  the  reader's  convenience.  The  fixes  shown  on  the  figure 


are  identified  as  follows* 


• ATI.  Atlanta 


• AND  Anderson 


• SNA  Nashville 


• CHA  Chattanooga 


si"  -C--*" 
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FIGURE  3 ATLANTA  CENTER  MULTISECTOR  STUDY  AREA 


HCH 

Hinch  Mountain 

OCR 

Norc  ro«s 

PSK 

Pulaski 

RHG 

Rome 

TOC 

Toccoa 

TYS 

Knoxville. 

The  Atlanta  Center  is  comprised  of  41  sectors.  Of  these 
the  nine  sectors  selected  for  study  control  priautrily  airline  arrival, 
departure,  and  cruise  traffic  north  of  the  Atlanta  airport. 

AT?  Multisector  Model  Structure 

The  primary  arrival  and  departure  airline  traffic 
routings  within  th:  Atlanta  Center  a.i'e  configured  in  a radial  pattern 
(four  arrival  and  ‘tour  departure  corridors)  with  the  Atlanta  airport 
as  the  focus.  The  study  area  modeled  by  ATP  Included  the  two  arrival 
corridors  frost  the  northeast  and  northwest  and  the  northbound  departure 
corridor.  The  nine  sectors  in  this  study  area  are: 

• Sector  36  (Allatcooa,  ALU) — high  enroute 
traffic,  FL330  and  above. 

• Sector  37  (Crossville,  CSV) — departure 
transition  traffic,  FL240-FL310. 

• Sector  38  (North  Departure,  MDEP}  — departure 
traffic,  FL120-FL230. 

• Sector  39  (Chattanooga,  CHA)-- arrival 
transition  traffic,  surface  to  FL270. 

• Sector  40  (Dallas,  9 DP)— arrival  traffic, 
FL120-PI270. 

• Sector  41  (Norcroes,  OCR)— arrival  traffic, 
PL120-PL230. 

• Sector  42  (Lanier,  2LI) --arrival  transition 
traffic,  FL240-FL310. 
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• Sector  43  (Pulaski,  PSK)--arriv*l  transition 
traffic,  FL24G-FL310. 

• Sector  44  (Baden-Blue  Ridge,  BAUBU)— high 
enroute  traffic,  FL330  and  above. 


i 


With  reference  to  Figure  3,  Sectors  39  and  40  arc 
in  the  northwest  arrival  corridor;  Sectors  41,  42,  and  43  arc  in  the 
northeast  arrival  corridor,  and  Sectors  J7  and  38  arc  in  the  northbound 
departure  corridor.  The  sectors  overlap  in  each  corridor  to  Corn  step- 
wise configurations  that  handle  cllnbing  >nd  descending  traffic  transition- 
ing in  and  out  of  the  Atlanta  TRACON.  Sectors  36  and  44  overlay  the- 
other  .vectors  (at:  noted  in  Figure  4)  and  handle  primarily  cruising  over- 
flights and  sosk  transitioning  aircraft. 

Arrivals  into  Atlanta  Center  from  directly  north 
generally  enter  Sector  42  at  FL310  or  l wer,  begin  descent  immediately, 
and  continue  the  descent  in  Sector  41  until  they  are  handed  off  to  the 
Atlanta  TRACTM  near  OCF  at  FL120.  The  arrivals  from  the  east  over  PSK 
in  Sector  43  or  Sector  44  arc  somewhat  higher  and  do  not  begin  descent 
until  approaching  the  border  of  Sector  42.  They  are  merged  with  th** 
arrivals  from  the  north  in  Sector  41  and  handed  off  to  the  Atlanta 
TRACON  near  OCR  at  FL120.  Arrivals  along  the  two  routes  from  the  notth- 
west  enter  Sector  40  at  FL2  '0  and  descend  to  FL.120  Just  south  of  IMG, 
where  they  are  handed  off  to  the  Atlanta  TRACON. 

Departures  to  the  north  diverge  in  Sector  38  and 
proceed  over  HCH  and  TYS  in  Sector  39.  Departing  traffic  generally 
crosses  the  center  boundaries  between  FL240  and  FL310. 

Three  major  cruise  routes  through  the  area  were 
modeled.  One  is  a two-directional  east/west  route  through  Sectors  37, 

42,  and  43  in  the  FL240  to  FL310  range,  and  though  the  overlying 
Sectors  36  and  44  at  FL330  and  above.  Prfcsary  fixes  along  the  route 
are  CHA,  TYS,  and  PSK.  Also  in  the  high  airspace  at  FL330  and  above 
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are  two  generally  nor'h/ south  routes.  The  first  crosses  Sector  36  and 
passes  ov-r  the  Atlanta  airport  (ATL) . and  the  other  crosses  Sectors  36 
and  44  and  passes  over  TYS  and  AND. 

A large  number  of  ssmII  volume  routes  were  also  in 
the  area  modeled,  but  are  not  shown  in  Figure  3,  and  include  the  arrival 
and  departure  routes  into  and  out  of  the  Chattanooga  airport.  Military 
activity  makes  up  about  10X  of  the  total  traffic  and  conforms  reasonably 
well  to  the  routes  followed  by  civil  aircraft.  Had  this  not  been  the 
case  we  could  have  included  routes  or  pset do  routes  for  this  traffic. 

A pseudo  route  would  be  a route  completely  enclosed  by  a sector.  The 
transit  for  this  route  would  be  the  average  time  a military  flight 

would  be  in  the  sector.  A p-.eudoroute  is  thus  a route  made  up  of  a 
single  arc  which  begins  and  ends  at  the  area  boundary  and  carries  mill* 
tary  traffic. 


Sector  a;d  Route  Network  Representation 

The  factorisation  and  routing  structure  shown  in 
Figure  3 is  abstracted  for  input  to  the  ATF  network  model,  as  shown 
schematically  in  Figure  4.  ATF  arc  number  Identities  are  indicated. 
Because  the  high  sectors  overlap  lower  ones  in  a stepwise  arrangement, 
we  juxtaposed,  in  Figure  4,  the  sector  schematic  presentations  to  diagram 
the  route  network.  The  overlapping  of  sectors  can  be  observed  to  some 
extent  if  the  figure  is  folded  along  the  dashed  lines  like  an  accordian. 
The  lower  sectors  should  be  folded  up  first.  The  two  high  sec tors --36 
and  44  (at  the  top  of  Figure  4)-- overlay  Sectors  37,  39,  42,  and  43; 
these  latter  four  in  turn  overlap  the  low  airspace  sectors— 3®,  40,  and 
41.  Diagrammatic  connectors  (circled)  were  included  in  Figure  4 to 
facilitate  smntal  piecing  (by  superimposing  connectors)  of  die  Juxtaposed 
sectors. 
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f IGURE  4 SCHEMATIC  OF  STUDY  AREA  ROUTE  MODEL 


In  the  conversion  from  the  actual  configuration  to 
the  schematic,  the  only  important  properties  (for  ATF  modeling)  of  an 
arc  are  the  transit  time,  the  origin  sector,  the  destination  sector, 
and  the  sector  including  the  arc.  Therefore,  if  two  or  more  arc.* 
originate  at  the  same  sector,  end  at  the  same  sector,  and  are  included 
in  the  same  sector,  they  may  be  combined  into  one  arc  whenever  transit 


times  are  equal* 

As  mentioned  earlier,  some  of  the  actual  routes 
have  two-directional  traffic  while  others  have  only  one-directional 
flow.  For  two-directional  routes,  two  logical  (ATF)  routes  were  defined 
to  represent  the  actual  r<*ute.  Consequently,  in  the  schematic,  each 
arc  shown  represents  one -dimensional  traffic  flow.  This  representation 
results  in  a system  of  nine  sectors,  26  routes  (or  origin-destination 
pairs),  and  42  arcs. 

It  can  be  seen  from  the  previous  discussion  that 
establishing  routes  for  the  Air  Traffic  Flow  model  is  of  primary  impor- 
tance in  setting  up  the  sector,  route,  and  arc  description.  The  follow- 
ing procedures  were  used  to  arrive  at  the  description  represented  in 
Figure  4. 

The  fir^t  step  is  to  gain  an  operational  understand- 
ing of  the  airspace  being  modeled.  He  have  found  that  interviews  are 
useful  in  establishing  the  primary  routes.  This  information  is  then 
used  to  help  structure  the  routes  from  flight  strips  (collected  at 
tho  center)  after  the  visit.  The  procedure  described  here  is  used  to 
obtain  arrival  counts  at  route  origins  as  well  as  defining  route  structure. 
Only  routes  with  substantial  traffic  ever  the  day  or  shift  being  simu- 
lated arc  included  as  logical  roua#.  Traffic  not  conforming  to  these 
routes  is  counted  as  part  of  traffic  on  a route  most  nearly  approximating 
the  flight  plan.  The  number  of  routes  is  dependent  upon  the  traffic 
patterns  and  the  level  of  detail  required  by  the  analyst.  Theoretically 
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there  could  be  one  route  for  each  aircraft  but  this  would  be  Impractical. 
Thus,  the  number  of  routes  is  determined  through  subjective  judtpsent 
during  the  flight-strip  reduction.  The  procedures  for  flight-strip 
reduction  are  not  rigid.  A suggested  approach  is  given  below  to  pro- 
vide insight  into  the  information  that  should  ' e sought  during  the  on- 
site interviews: 


1.  Sort  strips  by  aircraft  identification. 

Exclude  any  unmarked  strips. 

2.  Sort  by  civil  aviation  and  military  flights 
or  any  other  combination  of  traffic  classes 
with  different  predicted  growth  character- 
istics. 

3.  Sort  by  time  periods  (20-mln  to  1-hr  periods 
have  been  found  to  be  reasonable). 

4.  List  route  identification  based  upon  inter- 
views with  Center  personnel. 

5.  Tally  aircraft  entries  by  time  period  and 
route.  (Sector-to-sector  progression  of 
the  flight  is  the  most  important  factor 
in  assigning  aircraft  to  routes). 

6.  Establish  new  routes  for  any  reasonable  num- 
ber of  aircraft  which  do  not  fit  well  into 
the  routes  established  in  Step  4. 

Another  data  reduction  procedure  sorts  aircraft  by  route  after  Step  2. 
This  procedure  starts  with  the  primary  route  being  established  as  in 
Step  4 (eliminating  Step  3).  He  have  no  preference  for  either  procedure. 

The  end  result  of  this  procedure  is  a route-and-arc 
structure  representing  the  model  area  and  a count  of  arrivals  at  route 
origins. 


S.4.1.2  Traffic  Flow  Parameters 


The  els 


ts  of  this  input  type  are: 


arc  transit  times 


{fjjb  for 


10? 


and 

aircraft  arrival  rate*  {rk(T)},  for  ail  routes  k,  and  time  T. 

The  arc  transit  time  Is  calculated  at  the  average  aircraft  velocity  for 
aircraft  in  the  sector.  These  transit  times  can  also  be  derived  fror 
information  obtained  from  System  Analysis  and  Recording  (SAR)  tracking 
in  the  field.  Please  sec  Appendix  G for  further  information. 

The  other  input  parameter  Is  the  rate  of  aircraft  genera- 
tion at  the  origination  node,  rk(T),  for  each  route  during  cadi  time 
period.  The  general  approach  for  obtaining  the  traffic  count  is  to 
obtain  a basic  count  first.  The  basic  count  is  coded  and  used  as  input 
to  the  model.  The  ATP  model  is  then  run  for  at  least  one  run  without 
congestion  adjustment  to  evaluate  traffic  loads  by  sector. 

Hourly  sector  traffic  can  be  compared  to  the  lusy-Dsy 
Reports  from  the  center  being  modeled.  Por  example,  assume  the  model 
shows  the  following  relationship  for  aircraft  handled: 

busy  Day 


ATP  Output 

HtWiHL 

Sector  1 

20 

20 

Sector  2 

32 

30 

Sector  3 

35 

36 

The  analyst  should  search  for  the  routes  crosslr*  Sector  1 and  reAice 
flows  on  those  routes.  The  model  can  be  run  again  aid  the  same  compari- 
son made. 

If  future  operations  are  to  be  evaluated,  traffic  oust 
be  scaled  to  future  forecast  levels.  The  method  that  has  been  used  at 
SRI  has  been  to  deterministically  scale  the  traffic  load  by  route.  This 
has  been  done  manually  in  one  case.  He  also  have  a small  preprocessor 
program  which  will  scale  specific  types  of  traffic.  This  program  called 
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ADD  is  written  in  Fortran  and  ic  designed  to  take  the  base  case  traffic 
load  by  route  and  provide  an  incrementally  scaled  traffic  file  for  input 
into  the  ATF  model. 

The  overall  goal  of  scaling  traffic  is  to  gradually  in- 
crease traffic  throughout  the  center  until  its  capacity  value  Is  reached. 
It  is  desirable  for  purposes  of  delay  comparisons  to  have  higher  volume 
traffic  include  the  characteristic  pattern  present  in  the  basic  count. 
Thus,  if  Route  2 is  loaded  with  a basic  count  of  20  aircraft  per  flow 
period  (e.g.,  20  minutes),  it  is  desirable  to  have  those  20  aircraft 
plus  Route  2's  proportion  of  the  additional  traffic. 

The  scaling  methods  used  by  SRI  have  not  affected  the 
distribution  of  traffic.  For  example,  the  scaled  traffic  levels  for 
Atlanta  contain  the  same  relative  proportion  of  traffic  on  each  route 
that  is  found  in  the  base-case  traffic.  It  is  possible  that  actual 
future  traffic  may  be  heavier  on  routes  from  the  west  into  Atlanta. 
However,  we  had  no  basis  for  estimating  changes  in  distribution  in  fore- 
cast traffic  levels  and  so  none  were  made. 


5. 4. 1.3  Sector  Capacity  and  Workload  Coefficients 

RECEP  constants  corresponding  to  the  particular  automation 
being  evaluated  should  be  estimated.  This  is  done  by  adjusting  the  event 
times  according  to  the  estimated  enhancement's  design  goals  (see  Section 
VI,  Example  of  RECEP/ ATF  Application  in  Productivity  Analysis),  Con- 
stants may  also  be  adjusted  to  reflect  sector  reconfiguration  or  other 
proposed  changes  to  the  airspace.  The  new  constants  are  used  as  the 
input  by  sector  for  the  ATF  model.  Each  change  in  a sector  constant  is 
followed  by  a new  ATF  run.  The  results  are  evaluated  in  the  manner 
described  in  Section  VI. 
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5. 4.1. A Congestion-Relief  Strategies 


Two  congestion-relief  strategies  have  been  used  in  the 
Air  Traffic  Flow  model.  They  were  described  in  the  Section  V-A  (Model 
Overview).  It  is  possible  that  as  procedures  change,  different  congestion- 
relief  schemes  will  become  necessary.  This  should  become  apparent  to 
the  analyst  as  he  looks  at  the  flow  control  being  modeled. 


5.4.2  Output 

Output  from  the  model  is  printed  as  often  as  each  time  incre- 
ment or  at  any  other  frequency  desired.  The  amount  of  information  dis- 
played at  each  print  cycle  can  also  be  controlled. 


The  three  parameters  that  could  be  used  for  analysis  of  an 
ATC  airspace  are  avei^ge  delay  per  aircraft,  traffic  capacity,  and 
controller  workload.  These  three  elements  are  dependent  upon  each  other. 
Given  two  of  the  elements,  the  third  can  then  be  calculated. 


The  remainder  of  this  section  describes  the  ATF  output  item 
by  item.  Those  items  which  are  obvious  are  not  covered.  There  are  four 
basic  status  displays  as  shown  in  Table  18.  Items  are  defined  as 
follows: 


Sector  Status 

2 

Workload  ■ N + K^N  at  the  particular  time,  t. 


..  . over-all  time  steps  - 

Avg.  Work  ■ r—~ “ for  each  sector,  k. 

# time  steps  ’ 

Sector  count  ■ N at  the  particular  time  for  each  sector. 

Sector  entries  ■ number  of  aircraft  entering  sector  at 
the  particular  time. 

Sector  exits  - number  of  aircraft  leaving  sector  at  the 
particular  time. 
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Sector  delays  - count  of  the  number  of  aircraft  delayed 
in  the  sector  at  the  particular  time. 

Origin  delays  * count  of  the  number  of  aircraft  delayed 

at  the  boundary  of  the  entire  multisector 
sector  area  under  consideration  at  the 
particular  time. 

• Arc  Status 
Arc  count  * 

Arc  entries  ■ See  above  definition  for  sector  status. 

Arc  exits  * 

Cumulative  arc  delay  * Total  count  of  the  number  of  delays 

on  any  arc  up  to  the  particular  time. 

• Route  Status 

Cumulative  route  entries  » number  of  aircraft  to  enter 

each  route  not  counting  any 
delayed  at  the  origin. 

Cumulative  route  delay  * count  of  the  number  of  delays 

all  along  the  route  and  at  the 
origin. 

Average  route  delay  * cumulative  route  delay  divided  by 

cumulative  route  entries. 


• Aircraft  Status 

Aircraft  count  * number  of  aircraft  presently  in  the 
system. 

Aircraft  entries  * aircraft  entering  at  the  particular 

time  Increment. 

Aircraft  exists  ■ aircraft  exiting  the  system  at  the 
particular  time  increment. 

Cumulative  aircraft  delay  * count  of  the  number  of  delays 

in  the  system. 

CusHilatlvc  aircraft  entries  ■ cumulative  aircraft  to  enter 

the  system  not  counting  those 
delayed  at  the  origin. 

Average  aircraft  delay  ■ cumulative  aircraft  delay  divided 

by  cusulative  aircraft  entries. 

There  arc  two  procedures  for  stopping  the  Air  Traffic  Flow 
model.  The  first  is  to  terminate  the  aircraft  arrivals  with  an  input 
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card  with  FINI  on  it.  The  second  method  is  the  result  of  the  optional 
delay  termination  procedure.  Using  this  option,  if  one  of  the  delay 
maxima  is  exceeded,  the  program  will  stop.  In  both  cases  the  program 
will  first  zero  out  all  undelayed  aircraft  scheduled  to  enter  in  the 
future  and  continue  to  run  until  all  aircraft  in  origin  delay  queues 
have  entered.  The  program  then  prints  system  status  and  hourly  sunaaries 
(up  to  24  hours)  and  stops  if  there  is  no  new  inputs 


5.5  MODEL  APPLICATIONS 

RECEP  and  ATF  are  designed  to  allow  modification  and  flexibility 
to  their  design  structure  and,  thereby,  enable  their  application  to 
various  areas  of  study.  The  RECEP  event  task  times  and  frequencies 
uiay  be  used  to  represent  various  operational  requirements  and  strategics, 
and  ATF  parameters  may  be  used  to  represent  alternative  sectorization 
and  routing  structures.  The  possible  areas  of  application  for  RECEP/ATF 
include,  but  are  not  restricted  necessarily  to: 

• Evaluation  of  automation  packages, 

• Evaluation  of  operations  and  procedures, 

• Evaluation  of  ATC  manpower  allocation, 

• Testing  of  productivity  measures, 

• Energy  consumption  evaluation. 

To  date,  RECEP/ATF  has  been  applied  explicitly  to  the  first  area 
of  study  llsted--evaluation  of  automation  packages.  However,  this 
application  has  used  techniques  that  could  be  extended  to  the  other 
areas  of  study.  In  the  remainder  of  this  section,  we  briefly  review 
automation  package  evaluation  and  address  the  broader  implications  for 
RECEP/ATF  application. 
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’>.!>.  i Evaluation  ol  Automation  ParkuttcH 


Various  UG3RD  enroute  ATC  automation  concepts  currently  are 
under  examination,  RECEP/ATF  has  been  used  by  SRI  to  postulate  the 
operational  impact  o£  these  automation  alternatives  and  to  assess  their 
productivity  implications  relative  to  facility  staffing  requirements. 

These  analyses  are  in  various  stages  of  preparation  and  are  under  review 
by  the  Office  of  Aviation  Policy  of  the  FAA;  analyses  documentation 
will  be  forthcoming  upon  final  approval  of  the  results.  However,  a brief 
review  of  the  methodology  used  will  provide  some  insight  into  the  applica- 
tions of  RECEP/ATF  as  a tool  for  examining  the  feasibility  of  postulated 
automation  concepts. 

The  systems  were  examined  in  sequence  under  the  assumption 
that  each  automation  feature  is  added  to  the  previous  system.  The  auto- 
mation features,  added  consecutively  to  the  NAS  Stage  A Base  (System  1) 
are: 

« Automated  data  handling  (System  2). 

• Automated  local  flow  control  (System  3). 

• Sector  conflict  probe  (System  4). 

• Area  navigation,  RHAV  (System  5). 

• Discrete  Address  Beacon  System  (DABS)  data  link 
(System  6). 

• DABS  intermittent  positive  control,  IPC. 

5. 5. 1.1  Automated  Date  Handling  (System  2) 

This  first  add-on  to  System  1 Includes  the  implementa- 
tion at  sector  positions  of  an  electronic  tabular  flight  data  display, 
and  RDP/FDP  refinements.  The  tabular  display  is  an  electronic  flight 
data  presentation  designed  to  replace  paper  flight  strips  and  attendant 
manual  activities  and  would  effectively  automate  tome  controller  manual 
and  verbal  tasks  associated  with  intersector  control  procedures  and 
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flight  data  distribution.  The  RDP/FDP  refinements  are  minor  system 
modifications  that  would  facilitate  equipment  operation. 


5.5. 1.2  Automated  Local  Plow  Control  (System  3) 

This  feature,  which  we  assume  is  added  on  to  System  2,  is 
designed  to  maximize  sector  capacity  utilization  by  ssoothing  out  traffic 
peaking  situations.^  It  would  control  traffic  flow  on  routes  by  means 
of  an  on-line  computerized  traffic  planning  process  that  regulates 
workload  surges  in  accordance  with  the  traffic-handling  capabilities 
of  a multisector  environment.  It  impacts  on  enroute  operations  by  re- 
distributing traffic  peaks  and  workload  surges  on  the  air  traffic  route 
network. 


5. 5. 1.3  Sector  Conflict  Probe  (System  A) 

This  feature,  which  we  assume  is  added  on  to  System  3, 
alerts  controllers  of  potential  conflicts  and  reenwmends  resolution 
actions.  To  provide  an  operationally  realistic  time  prediction  horizon 
at  a low  false-alarm  rate,  we  assume  this  feature  will  be  used  when 
aircraft  first  enter  a sector.  Because  A/G  communications  are  required 
to  transmit  conflict  resolution  instructions,  workload  reductions  affect 
only  conflict  detection  and  assessment  tasks. 

5. 5. 1.4  RHAV  (System  5) 

This  feature,  which  wo  assume  is  added  on  to  System  4, 
incorporates  navigation  avionics  that  could  be  used  in  enroute  operations 
to  achieve  closely  spaced,  multilane  traffic  routes.  Overtaking  con- 
flict processing  would  be  eliminated  by  placing  successive  aircraft 
on  closely  spaced  parallel  routes. 
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5. 5. 1.5  DABS  Data  Link  (System  6) 


This  feature,  which  we  assume  is  added  on  to  System  5, 
transmits  to  pilots  digital  date  including  routine  clearance  and  conflict 
avoidance  directives.  It  is  not  intended  to  transmit  extensive  nonstandard- 
format  messages.  The  data  link,  integrated  with  extensive  coaqmteriza- 
tion,  is  the  basis  for  the  "control- by-exception"  concept  in  which  the 
controller  would  become  a system  manager  who  is  not  routinely  engaged 
in  rainute-by-minutc  tactical  decision  sulking.  He  would  have  to  awintain 
cognizance  of  the  computerized  sector  control  operation  and  intervene 
when  necessary  to  adjust  procedural  rules,  respond  to  pilot  requests,  and 
resolve  nonstandard  situations. 


5. 5. 1.6  DABS  IPC 

I PC  provides  traffic  advisories  and  threat-avoidance 
commands  to  pilots,  as  needed.  Because  this  service  could  operate  in 
the  enroute  environment  on  imminent  conflict  situations  that  might  be 
"missed-'  by  controllers,  we  assume  IPC  to  be  a safety-enhancement  device 
that  would  nor.  directly  impact  routine  staffing  requirements.  IPC  may 
bo  necessary  to  provide  fault  tolerance  in  the  event  of  failures  in  the 
other  enhancement  system  operations. 


These  systems  were  analysed  using  the  RECEP/ATP  formula- 
tions developed  for  the  Los  Angeles  Center  and  Atlanta  Center.  In  each 
case,  the  RECEP  and  ATP  descriptions  of  current  HAS  Stage  A operations 
were  revised  to  represent  ATC  operations  under  the  proposed  automation 
systems;  sector  capacity  and  delay  results  were  obtained  for  each  system 
(exclusive  of  IPC  which  was  assumed  not  to  affect  sector  capacity).  The 
RECEP/ATF  models  were  structured  to  represent  the  capacity/delay  relation- 
ships associated  with  various  manning  strategies.  This  technique  enabled 
the  estimation  of  the  staffing  required  to  maintain  currant  daisy  for 
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Increasing  levels  of  forecast  traffic  and  to  compare  the  corresponding 
productivity  implications  of  the  alternative  systems. 

He  note  that  RECEP  descriptions  of  automation  packages  require 
postulation  of  their  modes  of  operation  in  terms  of  the  work  activities 
of  controllers.  Therefore,  a subset  of  autoauttive  evaluation  is  the 
use  of  RECEP  to  describe  automation  operating  requirements,  which  could 
be  used  to  define  automation  design  specifications. 

5.5.2  Evaluation  of  Operations  and  Procedures 

As  part  of  the  analyses  of  manning  strategies  for  automation 
alternatives,  RECEP  was  used  to  estiauite  to  the  first-order  the  capacity 
effects  of  sector  splitting.  As  described  in  Appendix  H,  the  amthodology 
used  RECEP  to  approximate  the  redistribution  of  work  among  newly  created 
sectors  and  to  account  for  the  additional  sector  workload  induced  by 
introducing  new  sector  boundaries  (controllers  must  carry-out  control 
jurisdiction  transfer,  traffic  structuring,  and  related  activities  each 
time  an  aircraft  crosses  a sector  boundary).  Although  the  sector- 
splitting  model  was  desigc.sd  for  the  purpose  of  theoretical  analysis, 
the  concept  of  using  RECEP/ATF  to  analytically  compare  alternatives 
could  be  extended  to  the  evaluation  of  current  operations  and  procedures. 

RECEP  conceivably  could  be  refined  to  differentiate  not  only 
the  operational  impacts  of  inserting  sector  boundaries,  but  also  those 
impacts  of  adjusting  procedural  requirements  or  operational  rules-of- 
thumb.  For  example,  changes  to  standard  altitude  or  speed  restriction 
procedures  would  top-act  routine  work  activities,  and  decisions  to 
procedural iy  segregate  aircraft  routings  would  impact  potential  con- 
flict activities.  These  procedural  decisions  could  be  modeled  within 
the  RECEP  formulations  by  adjusting  event  task  tines  and  frequencies, 
and  assessments  concerning  the  effects  on  sector  capacities  could  be 
mode.  Clearly,  the  accuracy  of  such  assessamnts  would  depend  on  the 
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precision  with  which  operational  requirements  are  translated  into  work 
task  requirements;  these  requirements  are  understood  best  by  those 
personnel  knowledgeable  in  day-to-day  control  operations. 

ATF  in  conjunction  with  KECEP,  could  be  extended  as  a tool  to 
assess  and  plan  current  sailtisector  operations.  In  particular,  ATF 
might  be  refined  to  examine  the  means  by  which  adjacent  facilities  inter- 
act with  each  other.  This  approach  would  address  the  interface  between 
facilities  by  examining  the  formal  procedural  agreements  regarding 
routings,  in-trail  separation,  speed  and  altitude  restrictions,  and 
the  like,  and  could  be  used  to  assess  the  integration  of  tower/TRACOM/ 
center  procedures. 

5.5.3  Evaluation  of  ATC  Manpower  Allocations 

Resectorization  baaed  on  sector  splitting  is  one  way  of  in- 
creasing manning  to  handle  Increases  in  traffic  flow.  An  alternative 
is  to  expand  the  manning  of  existing  sectors  by  adding  controllers  to 
sector  teams  (e.g.,  expand  from  2 -sun  to  3-man  team).  Also,  a combina- 
tion of  both  approaches  may  be  used  to  match  manpower  capabilities  with 
traffic-handling  requirements.  The  evaluation  of  which  manpower 
allocation  technique — sector  splitting  or  sector  team  manning  adjustment — 
to  use  to  solve  current  operational  problems  could  he  modeled  on  KECEP/ 
ATF. 

RECEP/ATF  has  been  used  to  compare  multisector  manpower  allo- 
cations for  automation  alternatives.  This  application  used  KECEP  to 
estisiate  the  sector  capacity  impacts  of  sector  splits  and  team  manning 
adjustments,  and  used  ATF  to  identify  the  manning  force  needed  to  main- 
tain the  current  level  of  delay  for  various  traffic  projections.  Again, 
although  these  models  were  used  for  the  theoretical  analysis  of  postu- 
lated automation  systems,  the  modeling  approach  may  be  used  to  meet  the 
near-term  planning  needs  of  facility  personnel  to  make  trade-off 
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comparisons  between  sector  splittings  and  sector  team  manning  adjust* 
ments.  The  use  of  the  model  would  be  similar  to  those  applications  for 
automation  analysis  described  above;  however,  the  uses  in  this  case 
would  be  for  the  facility  operational  functions. 

5.6  DATA  BASE  UPDATE  AND  MODEL  VERIFICATION 

Similar  to  the  purpose  of  RE CEP  data  base  update  (Section  IV-E), 
the  AfF  data  base  for  a center  should  also  be  recalibrated  periodically 
to  reflect  the  most  current  operational  features.  These  features  in- 
clude sector  configuration,  route  structure,  traffic  flow  rates,  and 
congestion  relief  schemes.  The  current  operation  of  a center  often 
serves  as  the  base-line  for  an  ATF  simulation  for  future  productivity 
predictions;  therefore,  the  reliability  of  this  base-line  input  is 
iaqportant  to  the  simulation  results. 

The  ATF  data  base  update  (or  ATF  "quick  look"  field  test)  can  be 
performed  in  conjunction  with  the  RECEP  data  base  update  because  some 
of  the  common  data  elements  are  shared  by  both  models  (c.g.,  route 
structure).  RECEP  uses  it  for  potential-conflict  frequency  calculations, 
and  ATF  uses  it  for  route  and  arc  definitions. 

The  ATF  model  verification  requires  the  comparison  of  ATF  output 
(e.g.,  sectors  at  capacity)  with  some  other  known  data  such  as  center 
Busy  Day  Report,  Workpace/Work  Activity  records,  etc.  One  of  the 
methods  would  require  a series  of  straight  simulation  runs  each  for  a 
sufficient  period  of  simulated  time,  say  three  hours.  The  traffic 
parameters  are  scaled  for  capacity  throughput  (using  the  Busy  Day  Report 
as  one  of  the  data  sources).  A midhour  period  of  each  simulation  output 
will  then  be  compared  with  actual  field  data  collected  from  selected 
sectors  which  have  experienced  high  traffic  loadings.  An  agreement 
in  sector  workload  or  traffic  loading  statistics  between  the  simulation 
and  the  actual  field  data  would  constitute  a verification. 
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Another  nethod,  which  tehee  into  consideration  the  randan  varia- 
tions of  a dynamic  system,  would  be  to  perform  tine  aeriea  analysis  on 
ATF  simulation  output  (e.g„,  aircraft  loading  or  workload  values  at 
each  tine  increnent)  by  expressing  then  in  autoregressive  end  auto- 
correlation functions  (pp.  23-45,  Bef.  12).  Likewise,  the  real-world 
counterparts  of  ATT  simulation  responses  would  also  be  measured  (e.g., 
WA/WP  aircraft  loading  and  workpace  values  covering  the  sene  tine 
period  as  in  simulation)  and  converted  into  autoregressive  and  auto- 
correlation functions.  The  comparison  of  the  tine-series  functions 
between  ATF  output  and  field  measures  would  constitute  a verification. 
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6.  EXAMPLE  OF  RECEP/ATF  APPLICATION 
IE  PRODUCTIVITY  ANALYSIS 


The  methodology  previously  used  to  evaluate  automation  packages 
analyzed  the  relative  productivity  of  automation  a’ternativea  and  com- 
pared their  productivity  against  that  of  the  baseline  NAS  Stage  A opera- 
tion. The  productivity  comparisons  were  made  using  RECEP/ATF  to  estiawete 
manning  requirements  corresponding  to  traffic  projections  for  selected 
multisector  environaents.  RE CEP  was  used  tc  estimate  sector  capacities 
associated  with  alternative  manpower  allocations  for  each  automation 
pockage;  ATP  was  used  to  estimate  the  multisector  manning  needed  to 
maintain  current  delay  at  selected  traffic  projections. 

In  this  section,  we  demonstrate  the  productivity  analysis  applica- 
tion of  RECEP/ATF.  He  use  a hypothetical  automation  package  to  exemplify 
the  RE CEP  analyses  technique  and  illustrate  the  means  by  which  ATP  is 
used  to  develop  productivity  measures. 

6.1  RECEP  DEMONSTRATION 

We  describe  in  this  section  the  structuring  of  RECEl  models  for  a 
hypothetical  automation  package.  The  package  includes  Handoff  Augmenta- 
tion and  Sector  Conflict  Probe  automation  items,  for  which  we  will  de- 
velop workload  relationships  using  previously  established  RECEP  models 
of  current  NAS  Stage  A baseline  operations  at  the  Atlanta  Center.  The 
relevant  elements,  for  this  discussion,  of  the  baseline  system  RECEP 
models  are  the  routine  event  and  conflict  processing  task  times  previously 
presented  in  Tables  9 and  13.  In  the  remainder  of  this  section,  we  de- 
scribe the  impact  of  Handoff  Augmentation  on  routine  event  task  times 
and  tin*  impact  of  a sector  conflict  probe  on  conflict  event  task  times. 
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6.1.1  Handoff  Augmentation 


We  hypothesise  Handoff  Augmentation  as  a Halted  version  of 
the  electronic  tabular  flight  data  system  (STABS)  where  Handoff  Augmen- 
tation would  simplify  some  of  the  control  jurisdiction  transfer  task 
requirements  (as  defined  in  Table  9);  it  would  not  affect  traffic 
structuring  and  other  functions  nor  would  it  eliminate  the  need  for 
flight-strip  processing  (as  would  STABS). 

We  visualise  our  fictional  Handoff  Augmentation  systea  as  a 
small,  electronic,  alphanuaerlc-dlspla:  jyboard  unit  built  into  the 

sector  t cam's  current  operating  console.  The  display  lists  aircraft 
identity  (ACID)  data;  special  purpose,  quick-action  keys  are  located 
adjacent  to  each  ACID.  Manual  "punching”  of  one  such  key  would  activate 
handoff  acceptance  for  the  corresponding  ACID;  another  key  would  effect 
manual  handoff  initiation.  We  assume  two  such  keys  per  ACID  are  needed 
to  enable  retraction  of  handoff  Initiation;  otherwise,  a single  key 
would  be  sufficient  to  facilitate  both  acceptance  or  initiation  depending 
on  the  current  control  status  of  the  aircraft.  "Flashing"  or  "blinking" 
ACID  displays  would  accompany  the  handoff  operations  in  parallel  to  FVD 
data  block  flashing. 

We  develop  a BECEF  workload  model  of  the  Handoff  Augs  nation 
operation  by  making  the  adjustments  to  control  jurisdiction  transfer 
task  performing  times  as  summarised  in  Table  19.  The  parentheses  enclose 
the  baseline  system's  task  time  originally  presented  in  Table  9,  and 
the  remaining  data  entries  in  Table  19  correspond  to  the  Handoff  Aug- 
mentation enhanced  operatlou. 

With  reference  to  Table  19,  we  assume  that  the  Handoff  Aug- 
mentation will  reduce  the  time  required  in  FOF/KOP  operation  for  handoff 
acceptance  will  be  reduced  from  2 nan-sec  (baseline  system)  to  1 man-sec. 
In  tli In  case,  we  assimc  a 1 man-arc  augmented  keypunch  operation  (which 
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is  associated  with  a single  ACID  display)  will  automatically  identify 
the  aircraft  being  handed  off,  and  no  further  manual  keyboard/slew  ball 
operations  are  needed. 

He  assume  the  manual  (silent)  handoff  initiation  FDP/RDP  opera- 
tion will  be  reduced  from  3 man-sec  to  1 man-sec.  In  this  case,  the 
baseline  system's  manual  operations  needed  to  identify  both  the  aircraft 
and  receiving  sector  are  performed  automatically  when  the  augmented 
handoff  is  initiated  by  a 1 man-sec  keypunch.  The  augmented  display 
could  flash  the  ACID  as  well  as  the  receiving  sector's  identity  (deter- 
mined by  computer  from  FL?  flight  plan  data  files)  when  appropriate, 
and  the  controller  need  only  "authorize"  handoff  initiation  by  keypunch. 

Some  modeling  dexterity  is  needed  to  represent  more  detailed 
aspects  of  the  control  operations.  For  example,  the  term  handoff 
acceptance  as  used  in  the  Table  9 RECEP  formulation  includes  track  initia 
tions  for  FDP/RDP  operations  to  establish  computerized  radar  tracking  of 
a target,  and  manual  preparation  (writing)  of  a new  flight  strip  because 
no  FDEP  printed  flight  strip  would  be  available.  These  FDP/RDP  opera- 
tions would  also  be  required  to  establish  tracking  with  the  Handoff 
Augmentation  automation,  and  are  represented  in  Table  19  by  the  addition 
of  3 man-sec  of  FDP/RDP  operations  associated  with  original  10  man-sec 
for  new  flight  strip  preparation.  (The  baseline  system  FDP/RDP  opera- 
tions requires  3 man-sec  to  "capture"  the  target  by  slew  ball  and 
identify  the  aircraft  by  keyboard  data  entry.  For  modeling  convenience, 
the  3 man-sec  operation  is  represented  in  Table  9 as  2 man-sec  for 
FDP/RDP  operation  and  1 man-sec  for  flight  strip  processing.  These  task 
activities  are  required  for  a normal  handoff  acceptance,  and  are  used 
in  Table  9 as  a surrogate  measure  for  pop-up  tracking  because  no  handoff 
from  another  sector  is  actually  performed.) 


120 


' 

f 

5 l 


6.1.2.  Sector  Conflict  Probe 


'Hie  Sector  Conflict  Probe  wouM  j8c  computer-calculated  projec- 


tions of  flight  trajectories  to  identify  potential  conflict  situations. 


assess  the  situation,  and  recommend  resolution  actions  to  controllers. 
We  assume  this  device  would  be  integrated  with  the  Handoff  Augmentation 
operations;  conflict  probes  could  be  activated  automatically  each  time 
a handoff  acceptance  key  is  activated  or  could  be  activated  manually 
by  another  key  (i.e.,  third  key  set)  adjacent  to  an  ACID  display  on 
the  Handoff  Augmentation.  The  latter  capability  enables  early  and  se- 
lected probe  scanning. 


i 


The  sector  conflict  probe's  potential  effects  on  controller 
task  performance  times  are  estimated  as  shown  in  Table  20.  Again, 
baseline  system  task  times  obtained  from  Table  13  are  indicated  in 
parentheses.  Detection  and  assessment  tasks  are  performed  by  the  compu- 
terized probe,  and  resolution  directives/ suggestions  are  displayed  to 


TABLE  20 


CONFLICT  EVENT  PERFORMANCE  TIME  ESTIMATES 
ATLANTA  CENTER,  TWO -MAN  SECTOR  OPERATION 
SYSTEM  4~ SECTOR  CONFLICT  PROBE 


Conflict  Event 

Minimum  Task 
Performance  Time* 
(eau-sec /task) 

Minimum  Event 
Performance 

Detection 

and 

Assessment 

Resolution 

Time* 

(man-sec /event) 

Crossing 

5(20) 

40 

45(60) 

Overtaking 

5(20) 

20 

25(40) 

* 


Revised  System  2 performance  times  are  Indicated  in 
parentheses. 
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Che  R controller  (possibly  on  the  R-controller  current  computer  readout 
device,  CRD,  or  on  his  PVD).  We  judge  that  5 man-sec  will  be  sufficient 
to  assimilate  this  information.  Similar  to  current  baseline  system 
operations,  actual  resolution  is  performed  by  the  R controller  by  A/C 
conmunications.  A reduction  of  15  sec  in  total  conflict-processing  time 
results  for  both  crossing  and  overtaking  potential  conflicts. 

6.1.3.  Remarks 

The  revised  routine  and  conflict  processing  task  times  would 
then  be  loaded  into  the  RECEP  model  and  used  to  calculate  sector  capacities 
corresponding  to  the  automation  package  operation.  We  wish  to  emphasize 
that  our  automation  package  does  not  represent  current  FAA  development 
plans,  but  is  merely  a fictitious  automation  concept  that  we  use  for 
discussion  and  demonstration  purposes  only.  Furthermore,  we  do  not 
imply  that  we  are  recommending  the  enhancement  package  as  presented  for 
further  design  considerations.  Serious  questions  exist  regarding  the 
feasibility  of  introducing  additional  keyboard  and  display  facilities 
onto  the  current  console  design,  as  well  as  the  desirability  of  further 
complicating  control  operations  without  considering  restructuring  of 
all  task  requirements  on  an  integrated  basis. 

6.2.  ATF  APPLICATION  • 

We  use  ATF  to  estimate  the  average  aircraft  delay  experienced 
during  some  time  interval  of  interest  (i.e.,  8-hour  shift)  in  a selected 
multisector  environment  for  a range  of  traffic-loading  projections. 

The  multisector  environment  is  defined  by  specifying  the  route  network 
structure  and  control  operation,  baseline  or  enhanced.  The  control 
operation  is  represented  by  the  RECEP-based  workload-capacity  relation- 
ships determined  for  each  feasible  combination  of  baseline  or  enhanced 
system,  sector  manning  strategy  and  sectorizatlon  configuration.  For 
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the  purpose  of  productivity  analysis,  we  determine  and  compare  the 
average  aircraft  delays  corresponding  to  the  various  control  operations 
while  holding  the  route  structure  fixed.  The  procedure  Isolates  the 
delay  effects  of  automation  implementation  from  those  effects  relating 
to  route  structure. 

The  ATP  route  network  is  defined  for  the  baseline  system  using 
field  observation  data  collected  during  the  field  experiment  and  is 
used  also  to  represent  automation  system  routing  characteristics.  The 
ATF  route  network  developed  by  SRI  to  represent  a selected  9-sector 
system  for  the  Atlanta  Center  is  shown  in  Figure  4 as  an  example.  The 
route  network  is  defined  in  ATF  by  the  ordered  set  of  connected  route 
segments,  and  by  the  transit  time  through  each  sector. 

Traffic  loadings  on  each  route  during  successive  time  intervals 
(e.g.,  20-min)  are  obtained  from  the  field  data  collected;  the  traffic 
loadings  represent  the  current  traffic-handling  demand  placed  on  the 
baseline  system.  This  loading  is  increased  increawntally  to  represent 
future  traffic  demand  on  the  system.  The  various  traffic  loadings, 
current  and  projected,  are  applied  to  ATF  modelings  of  baseline  and 
automated  operations  to  enable  a parametric  comparison  of  delays  associ- 
ated with  each  system  at  fixed  traffic  levels. 


6.2.1.  Control  Operations  Modelin 


A control  operation  is  represented  in  the  ATF  model  by  the 
workload -capacity  relationships  defined  by  RECEP,  which  is  equivalent 
to  stipulating  the  maximum  number  of  aircraft  allowable  in  each  sector. 
ATF  loads  traffic  through  the  network  until  the  stipulated  sector  traffic 
capacities  are  reached,  and  then  delays  traffic  to  maintain  each  sector's 
traffic  flow  role  at  or  below  the  stipulated  capacity.  Therefore,  an 
increase  in  sector  capacities  will  increase  the  allowable  flow  rate 
through  each  sector  and  reduce  the  delays  induced  in  the  ATF  model 
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formulation.  This  attribute  of  ATF--the  sensitivity  of  delay  to  sector 
capacity--makes  the  model  a useful  tool  for  differentiating  the  opera- 
tional efficiencies  of  the  baseline  and  automated  systems. 

For  example,  consider  a comparison  between  a baseline  system 
and  a single  automated  one.  Let  us  assume  that  the  automated  system 
will  reduce  considerably  the  control  workload  requirements  per  aircraft, 
and  increase  the  sector  traffic  capacities  relative  to  the  baseline 
system.  Therefore,  an  ATF  run  for  the  automated  system  should  obtain 
a lower  average  delay  (e.g.,  over  an  8-hour  interval)  than  one  for  the 
baseline  system  under  couaitions  of  fixed-route  structure  and  traffic 
loading.  Similar  results  would  be  obtained  at  different  traffic  loadings. 
,'e  demonstrate  the  ATF  analysis  using  the  hypothetical  situation  shown 
in  Figure  5 where  the  current  traffic  loading  during  an  8-hour  shift 
on  some  current  10-sector  configuration  is  500  aircraft.  At  this 
traffic  level,  ie.  us  assume  the  ATF  average  delay  estimate  for  the 
baseline  operation  (with  current  sector  manning  strategies)  is  1 min/ 
aircraft,  while  the  corresponding  automation  system  delay  is  0.5  min/ 
aircraft.  Similar  pairwise  comparisons  between  each  system's  delay 
characteristics  can  be  made  at  projected  traffic  levels.  Figure  5 dem- 
onstrates successive  runs  of  the  ATF  in  which  traffic  increases  in  20X 
increments;  all  other  ATF  model  parameters  (i.e.,  route  structure  and 
sector  capacity  limits)  are  held  constant.  Interpolations  between  each 
delay  point  obtains  the  curves  shown.  We  note  that  Figure  5 exemplifies 
the  capability  of  ATF  to  translate  the  sector  capacity  advantages  of 
the  automated  system  into  delay  reductions  as  traffic  loading  increases. 


i a 


If  one  were  to  look  at  the  two  systems  under  a different 
sectorization  design  in  which  one  of  the  baseline  sectors  are  split, 
the  RECEP  analysis  would  show  an  increase  in  the  capacity  of  the  air- 
space of  the  original  sector.  Therefore,  rather  than  restructure  the 
ATF  route  network  to  model  the  two  new  sectors,  the  effects  of  the  sector 
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splitting  are  conveniently  represented  by  increasing  the  capacity  of 
the  original  sector  in  the  ATF  model.  The  resulting  delay  estimates, 
relative  to  traffic  loading,  could  be  as  shown  in  Figure  6 for  the  two 
systems. 

This  procedure  for  incorporating  control  operation  changes 
into  ATF  by  means  of  RECEP-based  capacity  adjustments  may  be  continued 
for  selected  automations  and  sec torizat ions,  and  of  course,  applied  to 
manning  strategy  alternatives. 

6.2.2.  Productivity  Comoarisions 

We  wish  to  compare  the  manning  and  traffic  handling  capabilities 
of  baseline  and  automation  system  at  some  common  level  of  service. 

Such  a comparison  enables  us  to  determine  the  efficiency  of  each  system's 
ability  to  provide  an  identical  service  quality.  For  this  purpose,  we 
use  the  current  level  of  delay  as  determined  by  ATF  for  the  baseline 
system,  and  compare  each  system's  operations  at  this  reference  point. 

We  need  to  estimate  the  manning  required  by  each  system  to  maintain 
current  delay  and  quantify  the  corresponding  traffic-handling  capability. 

To  demonstrate  this  approach,  we  use  the  examples  introduced 
in  Figures  4 and  S.  Let  us  assume  that  the  baseline  system  operation 
requires  2.5  men  per  sector  (i.e.,  one  R controller,  and  one  D controller, 
and  the  shared  services  of  an  A controller),  and  the  manning  strategy 
of  the  automated  operation  calls  for  2 own  per  sector  (i.e,,  eliminate 
the  A-controller).  Therefore,  the  baseline  system  requires  25  control- 
lers to  man  the  10-sector  configuration  and  27.5  controllers  to  man 
the  11-sector  configuration.  The  automated  system  requires  20  and  22 
controllers,  respectively,  for  the  10-  and  11-sector  configurations. 

Traffic-handling  capabilities  at  the  current  delay  level  cor- 
responding to  the  above  manning  levels  are  obtained  by  inspection  from 
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Traffic 

Manning 

Productivity 

Factor 

Factor 

Factor 

1.0 

1.0 

1.75 

1.1 

1.1 

1.0 

1.4 

0.8 

1.75 

1.6 

0.88 

1.81 

Figures  4 and  5.  The  current  10-sector  baseline  system  is  shown 
to  have  25  controllers  handling  500  aircraft/ shift  with  1 ■in/aircraft 
delay;  with  the  27.5  Manning  level  of  the  11-sector  configuration,  the 
baseline  systea  handles  550  aircraft  at  the  saae  delay  level.  The  auto- 
mated systea  with  20  aen  handle  700  aircraft,  and  with  22  aan,  the 
automated  systea  handles  800  aircraft  at  the  current  delay  level.  Using 
the  current  25  controllers  and  500  alrcraf t/shif t as  the  base  for  com- 
parison, the  productivity  factor  is  defined  as  the  ratio  of  traffic 
factor  to  sunning  factor  fur  current  level  of  delay  operations: 


System  Operation 

10- sector  Baseline 

11- sector  Baseline 

10- sector  Automated 

11- sector  Automated 


where: 

Traffic  factor  * Traffic  handling  capabllity/500  aircraft/ 
shift 

Hanning  factor  * Multisector  Banning/ 25  aen 

Productivity  factor  * Traffic  factor/staffing  factor 

The  statistics  shown  above  are  a soaple  subset  of  the  produc- 
tivity estimates  that  need  to  be  aade.  For  example,  we  see  that  the 
sunning  increase  associated  with  the  automated  system'  • single  sector 
split  increases  the  productivity  factor  froa  1.75  to  1.81.  Clearly,  we 
would  like  to  know  the  productivity  implication  of  further  manning 
Increases  and  the  limits  of  the  traffic  handling  capabilities  associated 
with  such  manning  Increases.  Therefore,  the  SRI  productivity  evaluation 
methodology  requires  the  IECEP/ATF  modeling  of  the  range  of  feasible 
manning  alternatives  associated  with  feasible  re sector lsat ion  and  sector 
manning  options.  This  procedure  paraamtrically  encodes  manning,  traffic 
handling,  and  productivity  relationships. 
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For  demonstration  purposes,  let  us  essiase  that  judgnentally 
based  analyses  (including  consultations  with  field  facility  personnel) 
concludes  that  the  original  10>sectors  could  each  be  split,  but  air- 
space 1 ini tat ions  would  preclude  further  resectorisation.  Therefore, 
the  number  of  sectors  eventually  obtainable  is  20,  which  results 

in  a manning  upper  bound  equal  to  twice  the  10-sector  canning  levels 
for  baseline  and  automated  operations.  RECEP/ATF  models  of  the  10- 
sector,  20-sector  and  selected  intermediate  configurations  would  obtain 
traffic  and  delay  relationships  for  each  operation.  (Alternative  sec- 
tor team  manning  strategies  would  also  be  modeled,  but  to  simplify 
this  discussion  we  do  not  do  so  here.)  These  relationships  would  be 
used,  as  described  in  the  preceding  paragraphs,  to  determine  a series 
of  traffic  and  staffing  factor  pairs  representing  current  level  of 
delay. 

Each  traffic  and  sunning  factor  pair  could  be  graphically 
plotted  as  shown  in  Figure  7 to  obtain  productivity  curves  for  each 
system.  Figure  7 presents  the  staffing  increase  needed  by  each  system 
to  maintain  current  delay  as  traffic  grows.  The  point  at  which  a 
system's  productivity  curve  reaches  its  manning  upper  bound  indicates 
the  traffic  capable  of  being  handled  at  current  delay.  For 

our  purposes,  we  refer  to  each  of  these  maximum  traffic  levels  as  the 
"capacity"  of  the  system,  although  additional  traffic  may  be  handled 
with  increased  delay.  Specifically,  the  "delay  constrained  capacity" 
of  each  system  is  the  traffic  handled  at  the  current  delay  level  by 
the  system's  maximum  practical  manning. 

We  say  compare  system  productivity  ratios  at  any  traffic 
factor  or  manning  factor  ratio  we  wish,  and  correlate  the  results 
with  yearly  traffic  forecasts  if  desired.  However,  for  general  pro- 
ductivity analysis  purposes,  we  will  compare  productivity  ratios  cor- 
responding to  the  delay-constrained  capacity  of  each  system. 
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FIGURE  7 PRODUCTIVITY  RELATIONSHIPS 


Recall  that  the  multisector  Manning  here  la  25  an  (1.0 
■anning  factor)  and  the  traffic  loading  base  la  500  aircraft/shlft 
(l.Q  traffic  factor)  with  reference  to  Figure  7,  the  20-sector  upper- 
bound  Manning  factor  fur  the  baseline  system  la  2.0  (l.e.,  50  controllers) 
and  Its  corresponding  traffic  factor  is  1.9  (950  aircraft/shlft).  The 
upper-bound  Manning  factor  for  the  automated  system  la  1.6  (l.e.,  40 
controllers),  which  corresponds  to  a traffic  factor  equal  to  2.6  (1300 
aircraft/shlft).  The  relative  efficiency  of  the  two  systems  operating 
with  maxlnui  manning  can  be  determined  by  coopering  productivity  factors: 


Traffic 

Manning 

Productivity 

Svstem  Operation 

Factor 

Factor 

Factor 

20-sector  Baseline 

1.9 

2.0 

0.95 

20-sector  Automated 

2.6 

2.0 

1.3 

Recall  that  current  10-sector  baseline  operation  is  assigned 
a productivity  factor  equal  to  1.0,  and  the  productivity  factor  of  the 
alternative  system  operations  arc  determined  relative  to  this  bat  .s  case. 
Therefore,  the  baseline  system  operating  at  maximum  staffing  shows  a 
"loss"  in  productivity  relative  to  current  operations  (i.e.,  0.95  versus 
1.0),  and  the  automated  system  counterpart  shows  a productivity  "gain" 
(i.e  1.3  versus  1.0). 

Analyzed  from  another  point  of  view,  the  baseline  system  may 
be  autintained  with  current  level  of  service  by  increasing  staffing  until 
traffic  grows  by  9 01.  Thereafter,  the  baseline  system  may  be  kept  in 
operation,  but  only  with  increased  traffic  delay  or  by  constraining 
traffic  demand,  or  both.  Let  us  suppose  that  traffic  is  forecast  to 
increase  by  90X  in  the  year  1985.  Our  analysis  suggests  that  some 
alternative  system  should  be  In  operation  by  this  time  to  maintain 
the  current  level  of  service.  Clearly,  our  hypothetical  enhanced  sys- 
ten  could  provide  such  service  beyond  1985  and  should  be  maintained  at 
the  latest  until  the  traffic  grows  by  1601. 

We  wish  to  point  out  that  controller  manning  requlresients  can 
be  expanded  into  annual  staffing  requireamnts  by  making  allowances  for 
standard  or  authorized  controller  relief  and  annual  leave  and  support 
and  supervisory  personnel  needs. 
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APPENDIX  A 

RECORD  FORMAT  FOR  EN  ROUTE  WORK  ACTIVITY  MEASURES* 


This  appendix  is  developed  froa  the  FAA  "before-and-after"  data  file 
formats  by  Mr.  Robert  tfiseaan  and  Dr.  John  Royal  of  the  Transportation 
Systems  Center. 
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APPENDIX  B* 


SECTOR  BUSY  HOUR  IDENTIFICATION  WITH  A WORKPACE  SEARCH  PROGRAM 


This  appendix  briefly  describes  a software  program  that  identifies 
the  busiest  sector  hours  in  a multisector  terminal  or  enroute  area.  The 
program  is  entitled  Workpace  Search  and  is  based  on  the  peer  evaluations 
of  controller  workpace  taken  in  the  field  experiments.  The  main  purpose 
of  this  program  is  to  select  data  for  further  processing  when  the  total 
of  observed  workpace  values  is  greater  than  totals  obtained  during  other 
days  of  a controlled  experiment  under  the  following  conditions: 

1.  A multisector  area  (say,  10  to  12  sectors)  has  been  se- 
lected as  a configuration  for  evaluation  over  a two-week 
test  period  (10  days). 

2.  Controller  workpace  is  observed  at  a maximum  of  four 
sectors  in  the  configuration  and  during  the  same  time 
each  day. 

3.  Workpace  observations  will  be  taken  for  one  and  one-half 
hours  at  each  sector  at  test  times  that  are  coincident 
with  RECEP  and  other  measures  taken  simultaneously. 

4.  The  start  times  of  Workpace  observations  at  each  sector 
may  differ  from  those  taken  at  other  sectors  by  as  much 
as  15  minutes. 

5.  Workpace  will  be  observed  at  one  or  two  selected  sectors 
for  all  ten  days  of  the  experiment  while  observations 
taken  at  other  sectors  may  vary  from  day  to  day. 


By  Mr.  Robert  Wiseman  of  the  Transportation  Systems  Center. 

A more  detailed  description  of  this  program  is  contained  in  "Workpace 
Search  Program,"  Draft  Report,  Dr.  John  Royal,  Kentron,  Hawaii  LTD, 
September  30,  1976. 
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Given  Che  test  condition#,  Che  Workpace  Search  program  uaea  a five* 
minute  moving  window  Co  find  Che  hour  over  which  each  sector's  workpace 
is  maximum.  The  program  Chen  totals  these  maximum#  for  all  observed 
sectors  for  that  day  to  select  three  one-hour  median  time  Intervals  when 
the  observed  Workpaces  are  maximum.  Although  this  selection  may  be  per- 
formed manually  as  a rough  data  screening  in  the  field,  three  other  fea- 
tures have  dictated  the  use  of  a computer  program.  These  are: 

1.  The  program  quickly  searches  past  workpace  data  on  the 
CDC  6400  data  files. 

2.  The  program  then  obtains  aircraft  counts  and  controller 
work  activities  from  the  same  data  files.  It  is  also  con- 
structed to  track  the  corresponding  minimum  task  times* 
for  man-second  comperisons  with  the  column  totals  in  the 
RECEP  routine  workload  measures. 

3.  Time  series  of  Workpace  and  aircraft  load,  sampled  every 
five  minutes,^  are  directly  formulated  for  coarse  com- 
parisons with  the  ATF  model  traffic  samples  and  sector 
workload  outputs. 


This  feature  will  require  the  collection  of  individual  (rather  than 
aggregate)  task  times  for  the  work  activities  listed  in  Appendix  C. 

t 

Finer  grain  comparisons  over  one-minute  intervals  are  made  from  the 
DART  aircraft  track  history  data  described  in  Appendix  G. 
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APPENDIX  C 


EQUIVALENCE  RELATIONSHIPS  BETWEEN  RECEP  AND 
WORK  ACTIVITY 

C.l  ONE-TO-ONE  EQUIVALENCE 

The  following  are  those  measures  of  the  systems  that  closely  approxi- 
mate each  other: 


RECEP 


WA 


A/G: 

• Initial  Pilot  Call-in 

• Pilot  Speed  Report 

• Traffic  Advisory 
FDP/RDP: 

• Equipment  Adjustment 

• Handoff  Acceptance 

• Handoff  Initlaticn 
INTERPHONE: 

• Planning  Advisory 

DIRECT  VOICE: 

• Handoff  Acceptance — 

Intersection  Coordination 


RADIO: 

★ * 

• AV  —Altitude  Verification  (131) 

• SV— Speed  Verification  (141) 

• AD-Advisory  (400) 

MANUAL— KEYPACK: 

• AE — Adjust  Equipment 

• Q— Handoff  Accept  (KRH) 

• Q— Handoff  Initiation  (RCH) 
INTERPHONE: 

• Cl— Coord  Inst  ion  with  Coordinator 

(CCI) 

VERBAL: 

• VH— Handoff  Received  Verbally  ( RHM) 


Prefix  to  WA  indicator  is  the  enroute  code.  Code  in  parenthesis  indi- 
cates teminal  code. 


140 


C.2  MANY-TO-ONE  EQUIVALENCE 


The  following  equivalence  relationship  involves  the  collapsing  of  a 
number  of  measuring  parameters  under  one  system  to  a single  aggregated 
parameter  under  the  other  system: 


RECEP WA 


A/C: 

RADIO: 

• 

Altitude  Instruction 

• 

AC— Altitude  Control  (130) 

• 

Pilot  Altitude  Report 

• 

Altitude  Revision 

• 

Heading  Instruction 

• 

VC— Vector  for  Control  (100) 

• 

Altimeter  Setting  Instruction 

• 

Runway  Assignment  Instruction 

• 

Pilot  Heading  Report 

• 

Transponder  Code  Correction 

• 

Hisc.  A/G  Coordinate 

• 

Frequency  Change  Instruction 

• 

Route/Head «ng  Revision 

• 

Hisc.  Pilot  Request 

• 

Speed  Instruction 

• 

SC— Speed  Control  (140) 

• 

Speed  Revision 

FDP/RDP: 

KEYPACK: 

• 

Pilot  Altitude  Report — 
Flight  Data  Update 

• 

Update/ Change/ Cancel  (DU) 

• 

Initial  Pilot  Call  in— 

Flight  Data  A l «.  itude— Insert 

• 

Altitude  Instruction— Flight 
Data  Altitude  Aaiendment 

• 

Transponder  Code  Correction 
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• 

Altitude  Revision— Flight 
Date  Altitude  Aaendaent 

• 

Route/Heading  Revision- 
Flight  Data  Route  Amendment 

• 

Flight  Data  Estimate  Update 

• 

Handoff  Acceptance — New 
Flight  Strip  Preparation 

• 

Q— Keyboard  (Action  Unknown)  (KG) 

• 

Pointout  Acceptance — Data 
Block  Suppression 

• 

Pointout  Initiation 

• 

Data  Biock/Leader  Line  Offset 

• 

Data  Block  Forcing/Reaoval 

• 

Miscellaneous  Data  Service 

FLIGHT  STRIP  PROCESSING: 

MANUAL: 

• 

All  Flight  Strip  Tasks— 

22  nonzero  entries 
(see  Table  9 for  details) 

• 

FS — All  Flight  Strip  Activities 
(FS) 

INTERPHONE: 

INTERPHONE: 

• 

Handoff  Acceptance— Inter- 
sector Coordination 

• 

HO— Handoff  Received  from  another 
Facility  (RHF) 

• 

HI — Handoff  Received  from  Complex 
in  Facility  (RHS) 

DIRECT  VOICE: 

VERBAL: 

• 

Handoff  Initiation— Inter- 
sector Coordination 

• 

VH— Handoff  Given  Verbally  (GHM) 

• 

Frequency  Change  Instruction 
— Intersector  Coordination 

1*2 


C.3  MANY-TO-MANY  EQUIVALENCE 

The  following  equivalence  relationship  is  on  a group- to-group  basis. 
All  of  the  data  elements  are  in  the  Interphone  Communication  and  Direct 
Voice  Comunication  areas: 


RECEP 


INTERPHONE: 


• Ha r. doff  Initiation — Inter- 
sector  Coordination 


INTERPHONE: 

• H0--Handoff  given  to  another 
Facility  (GHF) 


• Frequency  Change  Instruction — • HO--Handoff  Received  from 

Tntersector  Coordination  another  Facility  (RHF) 


• Altitude  Instruction— 

Intersector  Coordination 

• Heading  Instruction — Inter- 

sector Coordination 

• Speed  Instruction — Intersector 

Coordination 

• Pointout  Acceptance 

• Pointout  Initiation 

• Aircraft  Status  Advisory 

• Control  Jurisdiction  Advisory 

• Clearance  Delivery 


• CO— Coordination  with  another 

Facility  (CF) 

• Cl— Coordination  within  Facility 

(CS) 


Altitude  Revision — Intersector  • Cl— Coordination  with  Coordinator 

Coordination  (CCI) 


Route/Heading  Revision — 
Intersector  Coordination 


• 00— Coordination  with  Coordinator, 
Another  Facility  (CCF) 
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DIRECT  VOICE: 


VERBAL: 


• Altitude  Instruction-- 

Intersector  Coordination 

• Heading  Instruction--lnter- 

sector  Coordination 

• Speed  Instruction — Inter- 

sector Coordination 

• Altitude  Revision — later- 

sector  Coordination 

• Routc/Heading  Revision — 

Intcrsector  Coordination 

• Pointout  Acceptance 

• Pointout  Initiation 

• Control  Instruction  Approval 

• Aircraft  Status  Advisory 

• Control  Jurisdiction  Advisory 

• Clearance  Delivery 


• VR — Coordination  with  R Position 

(CR) 

• VL — Coordination  with  Handoff 

Position  (CH) 

• VD — Coordination  with  D Position 

(CFD) 

• CO — Coordination  with  another 

Facility  (CF) 


APPENDIX  D 


* 

POTENTIAL  CONFLICT  MODELS 

D.I  POTENTIAL  CONFLICT  FREQUENCY  MODEL 

This  appendix  describes  mathematical  models  for  estimating  the  ex- 
pected frequency  of  potential  conflicts.  Potential  conflicts  arc  pro- 
jected violations  of  separation  minima  perceived  by  controllers.  Because 
this  project  was  concerned  with  the  radar  environment,  the  ATC  radar  sepa- 
ration minima  are  the  criteria  to  be  maintained.  These  criteria,  based 
on  our  observations  of  the  actual  separations  exercised  by  controllers, 
are  as  follows: 

• Aircraft  are  separated  by  less  than  1000  feet  in  aLtltude 
(2000  feet  above  FL290) . 

• Aircraft  on  arrival  routes  about  to  enter  terminal  airspace 
are  separated  by  at  least  five  nautical  miles. 

• All  other  aircraft  are  separated  by  at  least  ten  nautical 
miles. 

The  two  primory  means  by  which  these  separation  minimuau  can  be  vio- 
lated are  by  (l)  intersecting  of  two  aircraft  flights  paths  or  (2)  one 
aircraft  overtaking  another.  The  possible  events  resulting  from  these 
two  violations  are  listed  in  Table  21. 

SKI  has  developed  a number  of  simple  a*,  chema  t lea  L models  for  pre- 
dicting the  expected  masher  of  events.  Data  acquired  in  our  measureswmt 
phase  were  compared  with  estimates  generated  by  these  models  as  verification. 


* 

This  appendix  is  extracted  from  Appendix  B,  Reference  7. 
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TABLE  21 


EVENTS  RESULTING  IN  VIOLATION 
OF  RADAR  SEPARATION  MINIMA 


Crossing 

Intersection  of  two  aircraft  flight  paths 

conflicts 

at  the  same  altitude. 

Intersection  of  a transitioning  (climbing 
or  descending)  aircraft  with  a level  air- 
craft at  altitude. 

Intersection  of  two  transitioning  aircraft. 

Overtake 

Aircraft  at  the  same  altitude. 

conflicts 

Aircraft  transitioning  on  the  same  track. 

The  development  of  the  model  used  to  predict  the  expected  number  of  con- 
flicts at  two  air  routes  is  described  in  detail  by  Siddiqee.1*  Only  the 
resulting  expressions  are  presented  here. 


Assume  the  following  statements  are  true  about  intersections  at  the 
same  altitude:  (1)  a conflict  event  occurs  any  time  an  aircraft  along 

route  1 is  closer  than  X miles  to  an  aircraft  along  route  2:  (2)  the  ar- 
rival of  aircraft  at  the  sector  entry  point,  along  the  air  route,  is  uni* 
formly  distributed  with  random  variations;  (3)  the  variation  in  aircraft 
speed  along  the  air  route  is  negligible.  Then,  the  relationship  for  the 
expected  number  of  conflicts  can  be  expressed  as 


ca-£ 
* i 


2 w/vW,  • «-  « 


VllVl2  •U  « 


-a1**!? 


**~*r.:r  TWiff 


where 

C is  the  expected  number  of  conflicts  per  hour. 

A 

f ^ is  the  flow  of  aircraft  at  altitude  i along  route  1 (aircraft 
per  hour) . 

f.^  is  the  flow  of  aircraft  at  altitude  i along  route  2 (aircraft 
per  hour) . 

X is  the  separation  minimum  (miles). 

v . ^ is  the  average  speed  of  aircraft  at  altitude  i along  route  1 
(miles  per  hour). 

is  the  average  speed  of  aircraft  at  altitude  i along  route  2 
(miles  per  hour) . 

a is  the  angle  of  intersection  between  the  routes, 
i is  the  different  altitude  levels  used  along  this  air  route. 

The  expected  number  of  conflicts  at  an  intersection  of  a transitioning 
aircraft  track  and  a level  aircraft  route  can  be  expressed  as 


Aiiiti.AiilV.Jidil  wJ.ji 


V is  the  average  speed  of  aircraft  along  the  j transitioning 
J track  (miLes  per  hour). 

th 

is  the  average  speed  of  the  aircraft  along  the  route  at  the  k 
altitude  (miles  per  hour). 

V is  the  transitioning  rate  for  the  transitioning  aircraft  (miles 
per  hour)  (i.e.,  climb  or  descent  rate  for  the  transitioning 
aircraft) . 

j is  each  transitioning  track  used  in  the  sector, 
k is  each  aLtitudo  Level  used  for  air  traffic  that  intersects  j. 


It  can  also  be  shown  that  the  expected  number  of  conflicts  at  an  inter- 
section of  two  transitioning  aircraft  routes  can  be  expressed  as 
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C is  the  expected  number  of  conflicts  per  hour, 
c 

f is  the  flow  of  aircraft  along  the  t ^ transitioning  route 

f 

(aircraft  per  hour). 

f is  flow  of  aircraft  along  the  m^  transitioning  route 
(aircraft  per  hour). 

X is  the  separation  minimum  (miles). 

is  the  average  speed  of  aircraft  along  the  l transitioning 
route  (miles  per  hour). 

V is  the  average  speed  of  aircraft  along  the  m^  transitioning 
route  (miles  per  hour). 
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V ^ is  the  transitioning  rate  for  the  aircraft  along  route  l 
(miles  per  hour) . 

t is  each  transitioning  route  used  in  the  sector, 
m is  each  transitioning  route  used  in  sector  that  intersects  l. 


Equations  (2)  and  (3)  are  used  only  if  the  situations  under  consider- 
ation pertain  to  transitioning  aircraft  and/or  level  aircraft  that  coin- 
cide along  the  same  ground  track.  If  the  situation  invoLves  aircraft 
along  different  ground  tracks,  then  the  expression  in  Equation  (I)  is  also 
used  to  determine  the  expected  number  of  conflicts  of  transitioning  air- 
craft and  level  aircraft  whose  ground  tracks  do  not  coincide,  as  well  as 
to  determine  the  expe-  ted  number  of  conflicts  between  two  different 
transitioning  aircraft  whose  ground  tracks  do  not  coincide.  Hence,  the 
exptcssions  in  Equations  (1),  (2),  and  (3)  give  estimates  of  the  expected 
number  of  conflicts  for  each  of  the  intersecting  situations  Listed  in 
Table  21. 

SKI  has  also  developed  a simpLe  mathematical  model  for  predicting 
the  expected  number  of  overtakes.  Assume  the  following: 

• An  overtake  event  occurs  anytime  a faster  moving  aircraft 
comes  within  X miles  (separation  minimums)  of  a slower 
moving  aircraft,  both  at  the  same  altitude  and  along  the 
same  air  route,  or  both  transitioning  along  the  same  route, 
during  the  period  of  time  the  aircraft  are  within  the  sector 
boundaries. 

• The  arrival  of  aircraft  at  the  sector  entry  point,  along  the 
air  route,  are  uniformly  distributed  with  random  variations. 

• The  variations  of  aircraft  speeds  along  the  route  are  dis- 
tributed In  discrete  speed  classes. 

Then,  the  relationship  for  the  expected  number  of  overtakes  along  an  air 
route  (including  transitioning  aircraft)  can  be  expressed  as 


<*  + 2X)  f , 
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0^  is  the  expected  number  of  overtakes  per  hour. 

n is  the  number  of  discrete  speed  classes  along  the  route. 

I is  the  length  of  air  route  (miles). 

f is  the  flow  of  aircraft  travelling  at  the  i*"^  speed  (aircraft 
per  hour) . 

is  the  beginning  speed  of  aircraft  in  the  i^  speed  (miles  per 
hour) . 

f is  the  flow  of  aircraft  travelling  at  the  k*"^  speed  (aircraft 
per  hour) . 

is  the  beginning  speed  of  aircraft  in  the  k^*  speed  class 
(mil •>3  per  hour). 

th 

V is  the  ending  speed  of  aircraft  in  the  i speed  class  (miles 
per  hour) . 

tH 

j'  is  Che  ending  speed  of  aircraft  in  the  k speed  class  (miles 
per  hour) . 

X is  the  separation  minumum  (miles). 


As  stated  above,  this  expression  also  includes  expected  overtakes  for 
transitioning  aircraft.  Hence,  Equation  (4)  gives  the  expected  number 
of  overtakes  for  two  overtake  situations  listed  in  Tab. e 21. 

Adding  the  expected  conflict  events  and  expected  overtake  events  to- 
gether yields  a total  of  four  possible  expected  conflict  events.  The 
frequencies  of  crossing  and  overtaking  conflicts  obtained  by  the 


K 


applications  of  these  models  will  be  used  as  functions  of  total  sector 
traffic  flow  in  the  RECEP  workload  calculation. 


D.2  SECTOR  CONFLICT  FREQUENCY  FACTORS 

Equations  (1),  (2),  and  (3)  estimate  the  expected  number  of  potential 
conflict  occurrences  for  a single  confliction  point  or  route  for  a given 
rate  of  flow  for  each  route.  These  relationships  may  be  used  to  calibrate 
a generalized  conflict  occurrence  model  in  which  sector  conflict  event 
frequencies  are  related  to  overall  sector  traffic: 

2 

Number  of  crossing  conflicts/hour  * e N 

c 


Number  of  overtaking  conflicts/hour  = e N 

o 


where 


N is  the  number  of  aircraft/hr  through  the  sector. 

e and  eQ  respectively  are  frequency  factors  that  measure  the  rates 
of  occurrence  of  crossing  and  overtaking  conflicts  for  the 
sector  measured  in  (conflicts/hr)/(aircraft/hr)2. 


The  frequency  factors  e and  e are  calculated  (as  discussed  below) 

c o 

using  Equations  (l),  (2),  (3),  and  (4)  for  a single  set  of  traffic  route 
flow,  route  distribution,  and  speed  class  data  for  a sector.  This  data 
set  describes  the  mutually  occurring  conflict  events  associated  with  one 
specific  hourly  traffic  flow  rate  through  the  sectors.  The  conflict  oc- 
currence results  we  summed  over  all  conflict  points  and  routes  to  obtain 
the  expected  number  of  potential  crossing,  E^,  and  overtaking,  E^, 
conflicts/hr  for  the  entire  sector: 

F.  = (C  + C + C ) for  all  intersections  points  x * 1,  2,  ... 

C ABC 


for  ail  routes  z =*  l,  2,  ... 


■rssc 


Recall  Chat  C. , C , and  f.  are  calculated  as  functions  of  pairwise 
A It  C r 

products  or  bilinear  functions  of  traffic  flow  rates  on  individual  routes 
through  the  sector.  The  corresponding  sector  traffic  flow  rate,  n,  mea- 
sured in  aircraft/hr  is: 


n * ^ n^  for  all  routes  z * 1,  2,  ... 


The  frequency  factors  as  a function  of  sector  traffic  are  calculated 


as  follows: 


Gc  = 2 


° »2 


Assuming  the  traffic  along  each  route  will  vary  in  direct  proportion 

to  the  traffic  distribution  used  in  our  calibrations  (and  that  other 

2 2 

parameters  also  remain  fixed),  the  products  e N and  e N estimate  the 

c o 

number  of  conflicts  per  hour  corresponding  to  any  value  of  N aircraft/ 
hour  through  the  sector.  Because  it  is  reasonable  to  assume  that  the 
traffic  distribution  remains  unchanged,  we  need  not  calculate  individual 
values  of  C , C , C , and  0 for  each  intersection  and  route  for  each 
value  of  N. 


APPENDIX  E 

DATA  COLLECTION  AND  REDUCTION  TECHNIQUES 
FOR  POTENTIAL  CONFLICT -EVENT  FREQUENCY 


The  primary  sources  of  data  for  the  potential-crossing  and  overtake- 
conflict  events  are  the  flight  progress  strips,  the  PVD  video  recording, 
and  controller-suppLied  information.  The  controller-supplied  information 
is  obtained  through  informal  meetings  and  interviews  and  is  essentially 
the  following: 


• Identification  of  potential  conflict  routes  and  potential 
conflict  situations  in  sector. 

• The  procedures  for  resolving  potential  conflict  situations 
in  sector. 

• The  selection  of  one  or  two  particular  examples  for  discus- 
sion. The  discussions  are  assisted  by  video  tape  play-backs. 

• The  minimum  separation  criterion  used  in  sector  (which  may 
be  more  stringent  than  the  standard  minimum  separation  re- 
quirement) . 

* 

For  clarity,  a flow  diagram  depicting  the  major  steps  involved  in 
RECEP  potential  conflict  event  data  collection  and  reduction  is  given  in 
Figure  8.  The  process  begins  with  identification  and  classification  of 
sector  and  route  characteristics.  Next,  the  potential  crossing-conflict 
routes  and  over take-conflict  routes  are  segregated  for  separate  processes. 
Each  cross-conflict  situation  would  result  in  using  one  of  the  three 
crossing-conflict  equations  given  in  Appendix  D and  the  overtake-conf lict 
situations  would  use  the  fourth  equation  given  in  the  same  appendix.  A 


This  flow  diagram  was  originally  contributed  by  Mr.  Robert  Wiseman  of 
TSC. 
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FIGURE  8 RECEP  DATA  COLLECTION  AND  REDUCTION  ON  POTENTIAL  CONFLICT  EVENTS  - MAJOR  STEPS 
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FIGURE  8 RECEP  OATA  COLLECTION  AND  REDUCTION  ON  POTENTIAL  CONFLICT 
EVENTS  MAJOR  STEPS  (Condudsd) 
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EACH  SPEED  CLASS 


HP’  EQUATION  141 


number  of  data  sources  are  used  ro  develop  variable  values  for  the  con* 
flict  equations.  For  example,  average  aircraft  velocity  (V)  «.nd  aircraft 
flow  rates  (F)  are  obtained  from  flight  strips  and  video  tape  recordings. 
The  major  data  sources  may  be  classified  as  follows  (the  alphabetic  item 
numbers  are  keyed  to  the  flow  diagram  boxes  shown  in  Figure  8): 

a.  Sector  identification  and  characteristics. 

b.  Operational  routes  and  flight  profiles. 

c.  Potential  crusslng>confl ict  intersections. 

d.  Average  speed  along  route  and  climbing/descending  rate 
for  transitional  route. 
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e.  Speed  classes  along  each  route  (for  potential  overtake 
conflict) . 

f.  Minimum  operational  separation  requirement. 

g.  Length  of  air  route  (for  overtake  events). 

h.  Aircraft  flow  rate  along  route. 

i.  Aircraft  flow  rate  for  each  speed  class. 

j.  Angles  of  intersection  (developed  from  a and  b above). 

Each  of  the  above  data  categories  is  also  linked  with  one  or  more 
source  data  elements  from  the  field.  This  relationship  is  shown  in  Table 
22  where  source  data  are  grouped  into  three  major  sources — fils'.  strips, 
PVD  video  recording,  and  controLler-supplied  information. 

To  further  illustrate  the  potential  conflict  data  processing  tech- 
niques, some  additional  examples  arc  given.  Figure  9 is  an  abstraction 
of  a sector  map  which  shows  the  routes  and  the  intersection:-:  pertinent 
to  potential  conflict  calculations.  A map  of  this  type  would  help  the 
analyst  to  identify  the  potential  confLict  situations  ro  develop  data 
required  for  further  processing.  Table  23  is  a bre  tdovn  of  the  routes 
(shown  earlier  in  Figure  9)  by  altitudes.  The  rer  c crosslng-conf lict 

frequency  calculation  is  given  in  Table  24  in  whicl  e conflict  pair  is 

shown  together  with  angles  of  Intersection,  flow  ra..-  velocities,  and 
the  average  number  of  conflicts.  Finally,  the  overtake  conflict  of  a 
route  is  illustrated  in  Table  25  where  the  speed  classes,  the  number  of 
aircraft  per  class,  and  the  calcula-.ed  average  number  of  overtakes  arc 
shown . 

In  the  data  reduction  effort  for  the  potential  conflict  calculations 
both  flight  strips  and  PVD  video  tapes  arc-  used.  They  tend  to  supplement 
each  other  in  obtaining  information  on  aircraft  velocities  and  flow  rates 
along  routes.  The  velocity  and  flow-rate  information  is  particularly  im- 
portant to  the  overtake-conf lict  equation  because  different  speed  classes 
along  each  overtake-conf lict  route,  as  well  as  flow  distributions  for  each 
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TABLE  22.  LIST  OF  SOURCE  DATA  ELEMENTS  FOR  POTENTIAL  CONFLICT  EVENTS 


Data  Element 

FLIGHT  STRIP  INFOKHATIDS:* 

Fro*  Flight  Plan 


Aircraft  Identification 
Sector  Ntnaber 

Sequence  Number  of  the  Flight  Strip 
Tlanned  Air  Speed 
Planned  Ground  Speed 
Route  Segment  Information 
Planned  Crossing  Time  at  a Fix 
(or  near  a fix) 

F'cn  Controller's  Nutation 


Initiation  or  Acceptance  of  llandoff 
Checkmark  (or  Pilot  Voice  Channel 
Frcqut  n<  y Change 
Actual  Altitude 

Cl imhing  «r  Descending  Hark 
Assigned  Air  I peed  (c.g. , speed  reduction) 

VIDKO  TAPE  INFORMATION  (PVD  + VOICE  CHANNEL): 

Sector  and  Center  Boundaries 
Airways  and  Special  Areas 

Vector  Lines  (Flight  Plan  Heading  and  Velocity) 

Cluck  Time 

Aircraft  Position 

Data  Block  (for  each  A/C): 

Aircraft  Identification  ar.d  Type 
Assigned  Altitude 
Repotted  Altltud* 

Har.doif  Initiation 
Handoff  Acceptance 

Speed  Instruction*  (e.g..  speed  reduction 
i .istrtietion— voice) 

D<parturo  1,1st 
S*  < tor  fnl»»ind  l.l*t 
Set  tor  Hold  l.ist 

la,w  or  High  Intensity  Heather  Display 

iiiki hdlli.k  sgpplhd  information 

(including  airway  maps) 


As  ARTS  ill  and  NAS  Stage  a model  ).d,2  are  lmpleswnted,  a number  of 
mai'ual  flight-strip  operations  will  be  replaced  by  other  means.  In 
tin  se  cast  s,  the  planned,  amended,  and  actual  flight  plan  information 
provided  l.v  t light  strips  may  be  obtained  from  two  automatic  data 
^records:  (l)  Flight  Plus  Data  Rase;  and  (2)  Tracking. 

See  Figure  8. 


operational  routes  and  intersections 


TABLE  23 


TYPICAL  TRAFFIC  DISTRIBUTION  EXAMPLE 

(N  = 30  Aircraft/Hour) 

H 


Altitude 

Route 

Combined 

Routes 

J84 

J5__ 

MV  A -MOD 

OAL-MOD 

FAT-LSfT 

RV  J92 

BIH-MOO 

4)0 

- 

390 

U 

si 

370 

6T* 

2 

IT 

350 

1 

li 

3l 

1 

11 

330 

2J 

1 

1 

IT 

310 

U 

U 

290 

280 

270 

It 

260 

250 

240 

Total 

B 

S 

2 

9 

2 

2 

2 

30 

The  arrows  indicate  whether  routes  are  descending  or  ascending. 


I 


TABLE  25 


OVERTAKE  CONFLICTS  (OAL-MOD  kOU’l'E) 
( Route  Length  = 75  Nautical  Miles) 


speed  class  aie  essential  t the  computation.  The  flight  strips'  role 
in  this  (besides  giving  aircraft  identification  information,  route, 
sector,  times,  etc.)  is  to  supply  ground-speed  information.  This  informa- 
tion is  currently  also  provided  by  the  PVD  display  but  not  in  all  cases. 
The  ground -speed  information  from  both  data  media  is  then  used  to  develop 
aircraft  flow  distributions  at  various  speed  classes  along  each  route. 


APPENDIX  F* 

USE  OF  DART  FOR  QUICK  ESTIMATION  OF  RECEP 
FDP/RDP  AND  AIRCRAFT  LOAD  COUNTS 


This  appendix  briefly  describes1  two  methods,  developed  by  TSC,  for 
the  semiautomatic  estimation  of  enroute  RECEP  FDP/RFP  operations  fre- 
quencies and  sector  aircraft  loads.  The  methods  employ  the  Data  Analysis 
and  Reduction  Tool  (DART)  program  on  the  IBM  9020  computer  to  obtain 
these  data  for  specified  sectors  and  over  selected  intervals  of  time. 

The  DART  program  is  available  to  perform  flexible,  off-line,  batch 
analysis  of  System  Analysis  Recording  (SAR)  data  that  are  always  gathered 
automatically  for  all  sectors  at  each  enroute  center  The  intent  is  to 
eventually  obtain  a rapid  and  fully  automatic  count  of  sector  aircraft 
load  and  FDP/RDP  keyboard/display  operational  counts  in  a form  suitable 
for  direct  use  in  the  RECEP  routine  workload  estimates.  Although  a 
complete,  fully  enumerated  routine  workload  data  base  requires  more  in- 
formation than  SAR  data  alone  can  provide,  it  should  be  remembered  that 
RECEP  events,  in  man-minutes  per  aircraft,  already  contain  judgmental 
estimates  of  minimum  times  and  often  require  other  data  sources  (such 
as  communications  and  video  tape  replays)  for  their  identification. 

The  method  developed  in  this  appendix  carries  the  RECEP  approximations 
a step  further  toward  automation  in  two  ways:  (l)  some  basic  FDP/RDP 


By  Dr.  Mitch  Grossberg  and  Mr.  Robert  Wiseman  of  Transportation  Systems 
Center  (TSC). 

more  complete  description  of  this  method  is  described  in,  "The  Use 
of  DAP.T  for  the  Quick  Estimation  of  RECEP  FDP/RDP  Workload  Operations 
and  Aircraft  Load  Counts,"  Draft  Interim  Report,  Dr.  M.  Grossberg  and 
R.  Wiseman,  DCT/TSC,  September  30,  1976. 


events  are  combined  into  a single  event;  and  (2)  Sector  Control  juris- 
diction of  aircraft  is  estimated  to  occur  when  the  manual  or  automatic 
handoff  action  is  sensed  by  the  NAS  computer.  These  approximations 
eliminate  cross-referencing  to  other  RECEP  measures  and,  when  coupled 
with  similar  approximations  in  controller  verbal  communications  and 
flight-strip  activities,  allow  a rapid  processing  of  data  into  the  RECEP 
matrix.  However,  it  should  be  noted  that  the  overall  purpose  of  these 
methods  is  to  assess  the  accuracy  of  RECEP  for  current  operations  and 
not  for  future  ATC  automation  enhancements.  In  the  latter  case,  it  may 
be  necessary  to  examine  individual  RECEP  events  and  aircraft  loads  using 
the  slower,  but  more  accurate,  original  methods  developed  by  SRI.  These 
considerations  are  discussed  in  the  descriptions  of  the  two  methods  which 
follow. 


F.l  ESTIMATION  OF  FDP/RDP  WORKLOAD 

This  method  focuses  on  the  KDP/RDP  operations  event  counts  under 
the  assumption  that  the  corresponding  minimum  times  for  each  event  are 
invariant  with  the  time,  controller,  and  site  location  of  any  current 
enroute  ATC  situation.  Given  the  invariance,  it  is  then  sufficient  to 
identify  only  the  number  of  each  FDP/RDP  event  to  obtain  an  individual 
man-minute  product.  The  DART  program  concerns  messages  that  are  entered 
into  a center'  '•omputer  by  the  P.  and  D controllers  from  their  respective 
data-enTy  devices.  The  controller's  computer  entries  define  the  occur- 
rence of  events  that  may,  in  the  real  situation,  also  involve  air 'ground 
conmmni cat i ons,  I light-strip  processing,  etc.  If  the  individual  FDP  RDP 
component  of  the  multiple  activity  events  is  identified,  then  it  is  not 
necessary  to  count  any  other  component  (for  example,  the  flight-strip 
processing  component).  That  is,  the  eventual  automation  of  FDP/RDP 
counts  will  also  partly  reduce  the  requirement  to  count  events  in  other 
columns  of  the  KECEP  matrix.  The  first  step  in  automating  the  FDP/RDP 


mu* 


operations  counts  starts  with  working  back  from  the  computer-entered 


messages  to  RECEP  events.  This  requires  a message- to-event  translation 


table,  one  designed  to  facilitate  look-ups  by  an  analyst.  The  analyst 


finds  a match  between  the  format  of  each  message  in  a DART  printout  and 


the  format  that  corresponds  to  a RECEP  event.  A match  may  involve  either 
the  message  type  alone,  when  all  possible  message  contents  apply,  or 


both  the  message  type  and  the  message  contents.  Having  identified  the 


corresponding  RECEP  events,  the  analyst  later  counts  the  number  of  mes- 


sages that  corresponded  to  a particular  event  and  multiplies  this  fre- 


quency by  the  minimum  performance  time  that  is  tabled  as  a constant  for 


this  event. 


To  obtain  the  FDP/RDP  man-minute  estimates,  several  simplifications 


are  made.  One  is  to  ignore  the  nature  of  the  controller's  interaction 


with  the  pilot  and  just  focus  on  actions  that  the  controller  takes  by 
himself--the  messages  input  to  the  computer.  For  example,  a DART  print- 


out can  indicate  that  a controller  made  a quick-action  keyboard  entry  to 


insert  an  altitude  value  into  a flight  plan,  but  the  printout  does  not 
indicate  whether  the  altitude  insert  was  prompted  by  an  initial  pilot 
call-in  or  by  a pilot's  altitude  report.  If  SAR  data  are  to  be  used 


independently  of  other  sources  of  concurrent  data  especially  taped  air/ 


ground  voice  communications,  then  the  analysis  cannot  deal  with  this 


distinction.  In  the  DART-based  analysis  of  SAR  data,  all  occurrences 
of  altitude  insert  actions  are  thus  represented  by  only  one  instead  of 


two  frequency  counts.  If  the  minimum  performance  time  for  each  of  these 


actions  is  the  same,  then  this  simplification  does  not  introduce  an 


error  into  the  estimate  of  total  workload.  In  this  instance,  the  time 


is  three  seconds  whether  the  altitude  insert  follows  a pilot  call-in 


or  a report.  Fortunately,  this  is  usually  the  case  when  events  are  com- 


bined. If  not,  the  times  for  each  event  must  be  approximated  by  an 


average  of  both. 


I'.fC.iuai*  message  content  as  well  as  message  type  are  both  needed  to 
translate  messages  to  RECEP  events,  the  Log  option  is  used  in  the  DART 
procedure  to  select  and  arrange  the  SAR  data  which  has  been  formed  on  an 
edited  tape.  Control  card  statements  are  used  to  limit  the  DART  out- 
puts to  preselected  sectors  and  specified  time  intervals  with  the  FDP/RDP 
messages  typrs  listed  in  the  RECEP  format  shown  in  Table  26.  The  table 
indicates  those  message  types  that  have  been  combined  or  eliminated  from 
consideration.  It  also  applies  to  both  R and  D controller  activities 
which  can  either  be  combined  or  separated  as  DART  outputs. 

Control  cards  are  also  used  to  arrange  the  printout  data  in  a way 
that  facilitates  message  matching.  This  is  obtained  through  a sorting 
hierarchy — DKVID,  C1D,  MESSACE,  and  TIME — causing  the  messages  to  be 
arranged  with  all  messages  grouped  by  sector,  then  by  aircraft,  then  by 
message  types,  and  finally  by  time,  so  that  all  messages  of  the  same 
type  are  in  the  order  of  their  occurrence.  The  resulting  printout  shows, 
for  example,  the  QN  messages  for  a given  aircraft  arranged  so  that  the 
handoff  acceptance,  altitude  amendment,  data  block  offset,  and  handoff 
initiation  messages  are  listed  one  after  the  other  in  order  of  entry. 

To  identify  the  corresponding  RECEP  event,  the  analyst  can  quickly  look 
up  QN  messages  and  compares  message  contents  with  prescribed  formats. 

An  efficient  computer  program  can  presumably  be  written  to  compare  these 
messages  with  the  tabled  formats  that  correspond  to  RECEP  events. 

K. 2 ESTIMATION  OF  A SECTOR'S  TRAFFIC  FLOW  RATE 

This  method  is  ba^ed  on  the  following  assumption:  until  a tracked 

aircraft  crosses  the  boundary  between  a sector  and  the  adjacent  sector 
or  facility  to  which  control  of  the  aircraft  has  already  been  transferred, 
the  radar  controller  in  the  sending  sector  is  required  to  maintain  sur- 
veillance over  the  aircraft  on  his  Plan  View  Display  (PVD) . Transfer 
of  control  jurisdiction  thus  does  not  end  all  of  the  sending  controller's 


activities  with  respect  to  an  aircraft;  nor  did  the  earlier  absence  of 
formal  control  acceptance  by  the  receiving  sector  mean  that  its  control- 
lers  were  not  already  maintaining  surveillance  over  an  expected  flight. 
Control  transfer,  viewed  in  terms  of  controller  behavior,  is  a gradual 
process.  However,  viewed  in  terras  of  the  enroute  f light-plan-aided 
automatic  tracker,  it  is  the  point  in  time  when  the  receiving  sector 
handoff  acceptance  is  entered.  The  present  method  for  estimating  the 
number  of  aircraft  controlled  by  a sector  relies  on  this  latter  defini- 
tion and  is  considered  sufficiently  accurate  for  sector  traffic  flow 
rate  estimates  made  for  both  R£CEP  and  the  ATF  model. 

Because  control  jurisdiction  confers  eligibility  to  make  certain 
changes  in  an  aircraft's  flight  data,  the  MAS  computer  keeps  a continuously 
updated  record,  the  Track  Control/Display  Table  (also  known  as  Table  HO) 
which  identifies  the  sector  that  has  jurisdiction  over  each  aircraft. 

Table  HO  is  included  in  SAR  data,  and  is  accessed  by  one  of  the  DART 
options.  Track,  whose  primary  application  is  the  detailed  analysis  of 
aircraft  position  as  a function  of  time.  The  point  here  is  that  use 
of  Table  HO  for  the  present  purpose  does  not  require  this  interpretation 
of  control  events.  The  use  of  Table  HO  eliminates  using  other  DART 
programs  which  conrider  transfer  of  a fairly  complex  series  of  control 
events,  both  manual  and  automatic,  in  two  sectors  and,  in  the  NAS  computer. 

A Track  printout  contains  three  lines  of  time-tagged  information  for 
every  six-second  period  in  each  aircraft's  track  history,  or  10  three- line 
samples  r f.  information  per  minute — a substantial  amount  of  potentially 
useful  information.  However,  only  the  fact  that  the  aircraft  was  con- 
trolled by  a particular  sector  at  a specified  time  is  needed  to  count 
the  number  oi  aircraft  in  a sector.  Using  data  control  statements,  the 
amount  of  printed  information  can  be  limited,  and  this  later  facilitates 
aircraft  counting  by  either  manual  or  automatic  means;  at  present,  auto- 
matic means  arc  not  available. 
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Control  statements  are  used  to  reduce  the  three  lines  of  informa- 


tion to  the  first  line,  and  the  10  samples  per  minute  to  one  sample. 

The  number  of  lines  is  reduced  by  setting  the  LINE  control  statement 
to  1.  The  sample  rate  is  reduced  to  one  time-tagged  sample  per  minute 
by  explicit  TIME  control  statements,  such  as  163000,163006.  Expressed 
in  hours,  minutes,  and  seconds,  these  times  are  the  start  and  end  of  a 
six  second  interval,  and  produce  a record  for  163001.5.  The  record  for 
the  next  minute,  that  is,  163101.5,  is  requested  using  the  interval 
163100,163106,  and  so  on.  Although  this  method  of  explicit  time  interval 
specification  is  tedious  to  express  when  entering  control  statements, 
and  is  a use  for  which  the  software  was  not  originally  intended,  it 
greatly  reduces  the  amount  of  data  in  the  printout,  making  the  printout 
manageable  for  manual  work. 

A Track  printout  that  is  obtained  for  a specified  time  period  (using 
the  "PARM"  control  statement),  say  a half  hour  and  with  one  line  of 
tracking  information  per  minute,  will  give  one  printed  page  per  aircraft 
for  all  aircraft  that  are  tracked  by  the  NAS  during  the  half  hour.  As 
shown  in  Table  27,  which  illustrates  a sample  DART  printout.  The  analyst 
scans  the  printed  column  of  sector  control  numbers,  asking  whether  a 
selected  sector  or  sectors  controlled  that  aircraft,  and  the  answer  is 
tabulated.  This  task  is  clearly  one  that  a computer  can  accomplish 
quite  efficiently. 

Whether  an  analysis  requires  a count  of  the  number  of  aircraft  con- 
trolled by  a sector  every  minute,  every  five  minutes,  or  every  hour, 
the  method  described  here  can  provide  the  needed  information  with  a 
constant  level  of  accuracy. 
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APPENDIX  G* 


A SUGGESTED  FIELD  TEST  PROCEDURE 
FOR  RECEP  AND  THE  ATF  MODEL 

A.  Purpose:  Field  tests  are  required  over  periodic  intervals  in  the 
next  two  years  to  validate  and  continually  update  the  predictions  made 
by  both  RECEP  and  the  Air  Traffic  Flow  (ATF)  model.  The  field  tests 
consist  of  lour  basic  types  with  the  following  purposes: 

1.  RECEP  "Quick- Look” : A two-  or  three-day  fiela  test  in- 

volving less  than  two  weeks  of  RECEP  data  processing  to 
recalibrate  its  routine  and  conflict  workload  estimates. 

2.  ATF  "Quick- Look”:  A one-week  test  involving  less  than 

three  weeks  of  RECEP  data  processing  which  provides 
either  an  initial  ATF  model  calibration  or  a subsequent 
recalibration  of  ATF  estimates  of  sector  traffic  capaci- 
ties and  delays. 

3.  RECEP  Validate:  A two-  or  three-wee*  test  in  which  prior 

"quick- look"  RECEP  estimates  are  first  compared  to  other 
field  measures  estimating  workload  and  traffic  capacities 
(e.g.,  peer  observations  of  workpace,  voice  channel 
utilization,  aircraft  proximity  weightings,  etc.).  De- 
pending on  the  degree  of  agreement  between  the  estimates, 
RECEP  will  be  declared  valid  for  the  current  operation  or 
a second  comparison  will  be  required.  The  latter  com- 
parison will  involve  the  use  of  RECEP  data  that  will  have 
been  taken  simultaneously  with  the  other  field  measurements 
and  will  result  in  either  a validation  or  recalibration 

of  the  estimates.  Data  processing  time  will  range  from 
four  to  seven  weeks. 

4.  ATF  Validation:  A series  of  three  or  more  RECEP  Validate 

tests  involving  less  than  six  months  of  data  processing 


This  appendix  is  primarily  supplied  by  Mr.  Robert  Wiseman  of  the  Trans- 
portation Systems  Center. 
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to  initially  establish  a 
tion  procedures  for  each 
sons  of  ATF  outputs  with 
multisector  simultaneous 
Workpace,  work  activity, 


validated  ATM  model.  The  valida- 
test  series  will  require  compari- 
ATF  "Quick- Look"  results  and 
field  measurements  of  controller 
capacity,  and  delay. 


Approaches 


1.  "Qu i ck- Look" — As  an  example,  a specific  approach  for  the 

RECEP  "quick  look"  is  as  follows: 

a.  for  each  of  four  or  five  sector  types  (low,  hi,  etc.) 
two  daily  traffic  conditions,  and  on  at  least  two 
different  days,  use  video  tape  replays  to  obtain: 

(1)  At  least  four  measures  of  the  each  conflict 
minimum  time; 

(2)  Traffic  distribution  by  arrival,  departure, 
aircraft  type,  and  route  mix;  and 

(3)  The  hourly  aircraft  count. 

b.  Identify  the  conflict  types  for  each  sector  from 
simultaneous  replays  of  the  video  and  alr/ground 
communication  audio  tapes. 

c.  (1)  For  each  sector,  obtain  the  total  tisie  per 

hour  for  R-controller  and  pilot  air-ground 
communication  from  a single-channel  audio 
tape. 

(2)  Take  at  least  four  measurements  of  the  R- 
contrcller  alr/ground  communication  minimum 
times  for  each  of  five  selected  events  in  the 
Traffic  Structuring  category.  Candidates  are: 
Initial  pilot  call-in;  altitude,  heading,  speed, 
altimeter,  or  frequency  change  instructions; 
and  craffic  advisories. 

(3)  Compare  the  shortest  of  the  times  -l*’  lined  in 
Step  c(2)  with  those  listed  in  Appendix  B. 

Insert  a new  time  in  the  lis*-  equal  to  the 
average  of  the  shortest  and  next  shortetc  of 
any  event  times  if  this  average  differs  from 
Appendix  B by  more  than  one  second. 
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(4)  For  each  sector,  the  counts  per  hour  for  each 
of  the  R-controller  air-ground  communication 
events  listed  in  Appendix  B. 

(5)  For  each  sector,  type,  compute  the  man-seconds 
per  aircraft  total  from  Steps  a(3),  c(3),  and 
c(4).  Use  the  new  total  if  it  differs  by  more 
than  10%  from  the  average  or  either  one  of  the 
totals  obtained  for  L.A.  and  Atlanta.  If  not, 
average  it  in  with  the  latter  totals. 

d.  Repeat  Steps  c(2)  through  c(5)  for  interphone  com- 

munication except  that  the  event  candidates  in  part  b 
will  be:  Intersector  coordinations  of  hand-off  events; 

printout  acceptance  and  initiation;  control  instruc- 
tion approval;  and  control  jurisdiction  advisory. 

e.  (1)  Take  at  least  four  measurements  of  K-controller 

KDP/RDP  operations  minimum  time  for  each  of  the 
following:  handoff  acceptance,  handoff  initia- 

tion, and  altitude  amendment. 

(2)  Repeat  the  procedures  of  Steps  c(3),  c(A),  and 
c(5)  for  RDP/RDP  operations. 


2.  Model  Verification 

The  RECEP  verification  could  involve  the  comparison  of  the 
RECEP  capacity  estimate  by  sector  with  the  Workpace  number.  We  would 
require  at  least  three  Workpace  estimates  at  different  traffic  levels 
for  each  sector.  It  is  not  expected  that  the  Workpace  number  versus 
aircraft  load  and  the  RECEP  workload  function  versus  aircraft  load 
functions  will  match.  Figure  10  shows  a probable  relation  of  these 
two  cuives.  It  is  possible  that  the  relationship  of  the  two  functions 
n.ay  assume  some  other  forms,  for  example,  the  Workpace  may  be  curvilinear. 

It  is  important  to  realize  in  Figure  10  that  the  curves  need 
i.ot  match  to  constitute  a valid  RECEP  model.  The  criteria  acceptance 
of  the  validity  of  RECEP  is  that  the  maximum  traffic  capacity  be  within 
a tolerance  range,  say  i5%  for  90%  of  the  sectors  tested.  The  RECEP 
methodology  uses  minimum  task  times  to  establish  the  maximum  sector 
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NUMBER  OF  AIRCRAFT 

FIGURE  10  PROBABLE  WORKPACE  AND  RECEP  CURVES  FOR  A HYPOTHETICAL  SECTOR 

capacity  for  each  sector.  Therefore  the  workload  index  (RECEP  scale  in 
man-win/hr)  should  be  below  the  Workpace  number  estimate  at  low  traffic 
levels.  They  should  only  match  at  capacity.  In  the  event  a match  is 
not  achieved  at  the  capacity  point  then  the  RECEP  estimates  may  be  re- 
calibrated to  be  more  closely  aligned  with  the  field  measurements,  or 
an  equivalence  function  be  established  between  the  two  measures. 


APPENDIX  H 


* 

THE  SECTOR  SPLIT  MODEL 


SRI  evaluated  the  effect  of  dividing  several  key,  bottleneck  sectors 
In  an  effort  to  increase  the  capacity  of  a multisector  area.  To  avoid  a 
t .me-consuming  sector  evaluation,  SRI  developed  and  used  a sector  work' 
load  model  in  which  the  total  sector  workload  is  described  as  the  sum  of 
the  route  workload  and  boundary  workload,  or 

W = W + :/ 

SAB 

where 

W is  the  total  workload  associated  with  an  ATC  jurisdictional 
S 

area  (such  as  a sector  or  a group  of  sectors). 

is  the  workload  associated  with  the  air  route  structure  (work 
related  to  events  such  as  conflicts  or  pilot  requests). 

W is  the  workload  associated  with  the  existence  of  sector 
B 

boundaries  (such  as  handoffs  or  coordination). 

The  W component  of  an  area's  total  workload  remains  the  same  for  any 

A 

given  traffic  Level,  regardless  of  how  the  areas  are  divided  into  sectors. 
The  boundary  workload,  however,  is  greatly  dependent  on  how  the  areas  are 
divided,  and  it  is  generally  proportional  to  the  number  of  boundary  cross- 
ings within  an  area.  SRI  deteimined  the  relationships  for  W and  W from 

A B 

the  collected  NAS  Stage  A data.  We  were  thereby  able  to  easily  determine 
the  total  arc..  workload  for  various  sectorization  schemes. 


A great  portion  of  this  appendix  is  extracted  fro*  dd.  117-11$  (Appendix  B) 
of  Ref.  7. 
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The  knowledge  of  the  area's  total  workload  for  n specific  sector 
configuration  was  used  in  the  following  model  to  estimate  the  traffic 
capacity  of  the  entire  area. 


where 

N^  is  the  area  traffic  capacity  when  area  is  partitioned  into 
i sectors,  therefore,  Nj  is  the  traffic  capacity  of  the 
single  sector 

Wtj  is  the  total  controller  workload  when  area  is  partitioned 
* into  i sectors. 

i is  the  number  of  sectors  in  the  area. 

For  the  particulai  case  of  dividing  one  sector  into  two  sectors,  this 
relationship  becomes 


The  use  of  this  relationship  facilitated  the  evaluation  of  sector  capacities 
for  use  as  input  into  the  ATF  model.  There  is  a potential  hazard  present 
in  the  use  of  this  relationship.  It  was  developed  under  the  assumption 
that  the  sectorlzation  strategy  equitably  divides  and  allocates  the  total 
area  workload  among  the  sectors,  and,  thus,  the  capacity  estimates  derived 
from  this  relationship  tend  to  be  somewhat  high  unless  this  condition  is 
fulfilled.  This  did  not  pose  a problem  in  the  SRI  evaluation  because  this 
condition  was  found  to  be  generally  satisfied  or  else  was  accounted  for 
by  subsequent  adjustments  in  the  capacity  estimates. 
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APPENDIX  I 


REPORT  OF  INVENTIONS 


After  a diligent  review  of  the  work  performed  under  this  phase  of 
the  contract  it  was  determined  that  no  innovation,  discoveries,  improve- 
ments, or  invention  has  been  made.  The  work  involved  the  revision, 
modification,  consolidation,  and  documentation  of  existing  software 
systems,  so  no  innovation  or  discoveries  were  expected. 
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